On Thu, 26 Jun 2014 10:16:41 -0500 Dan Williams <[email protected]> wrote:
> On Thu, 2014-06-26 at 01:19 -0500, Robby Workman wrote: > > On Thu, 26 Jun 2014 07:55:58 +0200 > > Vincent Bernat <[email protected]> wrote: > > > > > ❦ 25 juin 2014 21:36 -0500, Robby Workman <[email protected]> : > > > > > > > Okay, looks like that's ncurses, so let's link ncurses too: > > > > > > > > [rworkman@liberty NetworkManager-0.9.9.98]$ gcc -o testrl > > > > -lreadline -lncurses testrl.c [rworkman@liberty > > > > NetworkManager-0.9.9.98]$ strings testrl | grep readline > > > > libreadline.so.6 readline > > > > readline > > > > > > > > Now, here's where I'm unclear. If I add LDFLAGS="-lnurses" to > > > > the configure environment, the test passes and the complete > > > > build occurs successfully. What's unclear is *why* that's > > > > needed -- is this an omission in the NM sources (isn't nmtui a > > > > curses client and thus ncurses should be linked?) or is > > > > something different about how we (Slackware) build readline? > > > > > > GNU readline requires linking to ncurses as well to get termcap > > > symbols. Here is an autoconf recipe for that: > > > http://www.gnu.org/software/autoconf-archive/ax_lib_readline.html > > > > If I'm reading that correctly, that snippet above tries to link > > in curses if it encounters failure, so perhaps NM should use it? > > Maybe not though - there's at least one other project (nftables) > > where I've encountered the same problem. > > > > While digging around a bit after sending this, I found that we add > > "--with-curses" to the readline configure to use it instead of > > libtermcap, so it's *supposed* to be linked in already and this > > would not be a problem. However, for whatever reason (it's not > > clear whether it's intentional or not), the upstream sources don't > > use TERMCAP_LIBS (set to "-lcurses" per the configure flag) when > > building the shared library. It appears that at least one distro > > solves that by running 'make SHLIB_LIBS="-lcurses"' when building, > > but I don't see where Fedora did that, so it's not clear at all > > how they link curses (or even if they do, when means I wonder how > > the configure test in OP works there). > > > > Assuming this is indeed a problem, it's been in Slackware for years > > without causing any actual issues - the readline library from 13.37 > > (released in April 2011) doesn't link ncurses either, so I'm not > > convinced that we're doing anything wrong (but I'm open to > > argument). > > What does 'ldd' on your libreadline.so return? Mine has: > > linux-vdso.so.1 => (0x00007fff191fe000) > libtinfo.so.5 => /lib64/libtinfo.so.5 (0x0000003473400000) > libc.so.6 => /lib64/libc.so.6 (0x000000345ac00000) > /lib64/ld-linux-x86-64.so.2 (0x000000345a800000) > > so at least the dynamic linker knows that libtinfo (provided by > ncurses) is required here, and should load that in for the configure > test program. # ldd /usr/lib64/libreadline.so.6 linux-vdso.so.1 (0x00007ffff43ff000) libc.so.6 => /lib64/libc.so.6 (0x00007ffda6b37000) /lib64/ld-linux-x86-64.so.2 (0x00007ffda7179000) I don't have any links to support this, but in talking with a couple of folks who've "been around a while," it seems that the lack of direct linking is intentional on the part of upstream readlinke -- this allows the specific apps to use whichever (termcap / ncurses) is appropriate for them. The autoconf stuff linked earlier seems to somewhat support that, but again, I don't have a definitive answer on it. I am fairly certain though that libreadline *directly* linked to either tinfo (which is actually ncurses) or termcap requires some sort of deviation from the upstream build options -- Fedora explicity links tinfo, while Arch explicitly links ncurses. Perhaps it's not a battle worth fighting at this point, but I'd prefer not to see other projects (e.g. NM) dependent upon distro-specific enhancements of upstream libraries. That said, perhaps the path of least resistance is to just explicitly link ncurses with our readline library. That's not my decision though :) -RW _______________________________________________ networkmanager-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/networkmanager-list
