Re: ANN: NetworkManager (0.9.10-rc1) released

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-]$ gcc -o testrl
-lreadline -lncurses testrl.c [rworkman liberty
NetworkManager-]$ strings testrl | grep 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:

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

What does 'ldd' on your return?  Mine has: =>  (0x00007fff191fe000) => /lib64/ (0x0000003473400000) => /lib64/ (0x000000345ac00000)
      /lib64/ (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/ (0x00007ffff43ff000) => /lib64/ (0x00007ffda6b37000)
        /lib64/ (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 

That said, perhaps the path of least resistance is to just explicitly
link ncurses with our readline library.  That's not my decision though :)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]