Re: ANN: NetworkManager 0.9.9.98 (0.9.10-rc1) released

[Robby Workman <robby rlworkman net>]

On Thu, 26 Jun 2014 10:16:41 -0500
Dan Williams <dcbw redhat com> wrote:

> On Thu, 2014-06-26 at 01:19 -0500, Robby Workman wrote:
> > On Thu, 26 Jun 2014 07:55:58 +0200
> > Vincent Bernat <bernat luffy cx> wrote:
> >
> > >  ❦ 25 juin 2014 21:36 -0500, Robby Workman <robby rlworkman net> :
> > >
> > > > 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