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

[Robby Workman <robby rlworkman net>]

On Thu, 26 Jun 2014 15:49:20 -0500
Dan Williams <dcbw redhat com> wrote:

> On Thu, 2014-06-26 at 14:58 -0500, Dan Williams wrote:
> > On Thu, 2014-06-26 at 12:44 -0500, Robby Workman wrote:
> > > On Thu, 26 Jun 2014 12:27:14 -0500
> > > Robby Workman <robby rlworkman net> wrote:
> > >
> > > > 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.
> > >
> > >
> > > ...and comment #1 seems to support that (but apparently the
> > > official RH position changed since then):
> > >
> > > https://bugzilla.redhat.com/show_bug.cgi?id=162023
> >
> > Fun.  nmcli doesn't care which one you link with, so NM would rather
> > just use whatever you have lying around.  Unfortunately it seems we
> > have to make the user specify one?
>
> Robby, can you test the attached patch?  If it works for you we'll try
> to get it into git master and 0.9.10.


Yep, configure test for readline passes, the build completes successfully,
and the nmtui binary at least runs (I've not actually running the NM daemon
version yet, so I can't really test functionality).

Thanks for the patience and help on this :-)

-RW