| Summary: | sysutils/tmux USES=ncurses seems to be a no-op | ||
|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Vick Khera <vivek> |
| Component: | Ports Framework | Assignee: | Port Management Team <portmgr> |
| Status: | Closed Not Enough Information | ||
| Severity: | Affects Only Me | CC: | portmaster, ports-bugs, ports, swills |
| Priority: | --- | ||
| Version: | Latest | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
Vick Khera
2016-01-21 16:42:02 UTC
(In reply to Vick Khera from comment #0) > A while ago I reported a bug I observed using the sysutils/tmux program in > bug #193685 > > The TL;DR is that I needed tmux to be linked using the ports ncurses rather > than the system ncurses to avoid display errors in certain circumstances. > > Fast forward to today (well, a while ago, but I cannot pinpoint exactly > when) it seems that the build of tmux is registering a dependency on the > ports ncurses package, but is not actually linking against it. This used to > work, but some update between the original bug fix and now causes it to not > link to the ports ncurses. Perhaps it is that I'm running FreeBSD 10.2 now? > > This is what I see: > > [root@lorax]# ldd /usr/local/bin/tmux > /usr/local/bin/tmux: > libutil.so.9 => /lib/libutil.so.9 (0x80088c000) > libncurses.so.8 => /lib/libncurses.so.8 (0x800a9e000) > libevent-2.0.so.5 => /usr/local/lib/libevent-2.0.so.5 (0x800ceb000) > libulog.so.0 => /lib/libulog.so.0 (0x800f2e000) > libc.so.7 => /lib/libc.so.7 (0x801130000) > libthr.so.3 => /lib/libthr.so.3 (0x8014dc000) > libmd.so.6 => /lib/libmd.so.6 (0x801700000) > [root@lorax]# pkg info -dr tmux > tmux-2.1_1 > Depends on : > libevent2-2.0.22_1 > ncurses-6.0_2 > > And the problem persists with the display errors. > > If I use my workaround and install the following libmap entry, I get tmux to > link to the ports ncurses, and then the display bugs go away. > > [root@lorax]# cat /usr/local/etc/libmap.d/tmux.conf > [tmux] > libncurses.so.8 libncurses.so.6 > [root@lorax]# ldd /usr/local/bin/tmux > /usr/local/bin/tmux: > libutil.so.9 => /lib/libutil.so.9 (0x80088c000) > libncurses.so.8 => /usr/local/lib/libncurses.so.6 (0x800a9e000) > libevent-2.0.so.5 => /usr/local/lib/libevent-2.0.so.5 (0x800cc3000) > libulog.so.0 => /lib/libulog.so.0 (0x800f06000) > libc.so.7 => /lib/libc.so.7 (0x801108000) > libtinfo.so.6 => /usr/local/lib/libtinfo.so.6 (0x8014b4000) > libthr.so.3 => /lib/libthr.so.3 (0x8016eb000) > libmd.so.6 => /lib/libmd.so.6 (0x80190f000) > > > I tried modifying the port to set USES=ncurses:port and also added the > NCURSES_RPATH=yes variable. Neither one resulted in a suitable library link. > > While this is immediately noticed using tmux, I think it may be all ports > that are affected. For example, the sysutils/tty-clock port also specifies > USES=ncurses yet links to the base system ncurses when ports ncurses is > installed. > > > [root@lorax]# uname -r > 10.2-RELEASE-p7 Hello, While I'm not the Maintainer; it appears to me that the port is choosing the $BASE version library, before attempting to use the ports version. As seen here: LIBEVENT_STATIC_BUILD_DEPENDS= ${LOCALBASE}/lib/libevent.a:devel/libevent2 Note that devel/libevent2 is chosen *after* ${LOCALBASE} Have you attempted to reverse that order, and try again? --Chris I'm not following at all what libevent has to do with this. You will also see the same effect with sysutils/tty-clock which uses no other libs but libc and ncurses. What more information do you need? I think it is pretty clearly spelled out that the port is registering a dependency yet not linking to the library from that dependency. Or has it just been "overcome by events" and works now? |