Re: [Bug-readline] Linking Shared libreadline with(out) TERMCAP_LIB

[Dmitrii Pasechnik]

On Tue, Apr 23, 2019 at 10:56:53AM -0400, Chet Ramey wrote:
> On 4/23/19 5:44 AM, Dmitrii Pasechnik wrote:
> 
> Responding to a five-year-old message?
yes, because it was not really acted upon, and nothing changed.

> 
> > Why is this done? This is error-prone, as the linking application has to
> > figure out which termcap library was meant to be used with the readline;
> > one cannot assume that a random one would work just fine.
> 
> A "random" termcap library should be just fine, as long as it provides
> the correct symbols. Readline is not "meant to be used" with any
> particular termcap implementation; as long as it provides good information,
> you can use anything.

With underlinking like this, one has too little control over the origin
of symbols used by readline.  There is no guarantee that out there in
the flat namespace there is e.g. an UP symbol that has nothing to do
with termcap.  With underlinking, the process using readline would start
and carry on, and then crash, or worse.

> 
> > Without pkg-config supplying this info, this is hard, if not impossible.
> > (and even with pkg-config supplying the correct extra -l..., this makes
> > the setup more complicated than it should be).
> > It appears that all major linux and *BSD distros
> > simply patch readline to be linked with the appropriate termcap library.
> > E.g. on Fedora 26:
> > $ ldd /usr/lib64/libreadline.so
> >         linux-vdso.so.1 (0x00007ffc12903000)
> >         libtinfo.so.6 => /lib64/libtinfo.so.6 (0x00007f28a631c000)
> >         libc.so.6 => /lib64/libc.so.6 (0x00007f28a5f47000)
> >         /lib64/ld-linux-x86-64.so.2 (0x00007f28a6794000)
> 
> This is a reasonable choice for a distribution to make. There's nothing
> wrong with it.

If everyone patches your code at some place then you ought to consider that it
might have a bug there :-)

> >> The problem, if one exists, is probably in defaulting TERMCAP_LIB to
> >> -ltermcap.
> > 
> > this is certainly a bug, and it stems from BASH_CHECK_LIB_TERMCAP
> > hardcoding the order of libraries to check, with termcap always first,
> > regardless of --with-curses supplied, or not.
> That's not the problem. TERMCAP_LIB has to default to *something* in the
> case we're discussing: autoconf didn't find an appropriate library and
> there will be undefined symbols.

I don't think we are discussing the case where ./configure
(I presume you meant configure rather than autoconf)
didn't find anything useful. Here ./configure
works, and sets TERMCAP_LIB, which is then not used on
any platform apart from cygwin/mingw. And we get an underlinked shared
library not because configure failed to set TERMCAP_LIB, but because it
was not used by support/shobj-conf.

E.g. with readline from the git master branch
./configure --with-curses --disable-static --prefix=/tmp/blah
on linux with both termcap and ncurses installed
results in
...
configure:6313: checking which library has the termcap functions
configure:6316: result: using libtermcap
...
and then, weirdly,
TERMCAP_LIB='-lcurses'

which is then ignored anyway, and one builds an underlinked library:
$ ldd /tmp/blah/lib/libreadline.so
        linux-vdso.so.1 (0x00007fffddb1a000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x0000780929cfb000)
        /lib64/ld-linux-x86-64.so.2 (0x000078092a2e8000)

> I agree that --with-curses should inhibit checking for libtermcap using
> AC_CHECK_LIB. If you have a patch for that, please send it.

I will.

> 
> > IMHO, termcap should not be checked if the option is on, at all.
> > Anyway, with --with-curses supplied, termcap must to be checked ahead
> > of tinfo/(n)curses.
> 
> I assume you mean --with-curses means that termcap must *not* be checked
> before libtinfo/curses/ncurses/ncursesw.

Yes, indeed, sorry for the typo.

> > I'd be glad to supply patches for these two related issues.
> 
> Sure, please send them along. It might also be worthwhile to add a
> --force-termcap (or similar) option to readline's configure script to
> link the shared library against termcap/curses, as some distributions do.
I'd like to argue that this would be a confusing option naming. If I specified
"--with-curses --disable-static" I should get readline linked with
(n)curses already, not something underlinked.

I'd say that I'm OK with underlinking if there was no --with-curses or
(non-existent, but easy to add) --with-termcap.
But to specify --with-curses and end up without (n)curses is just wrong.
It's akin to ordering coffee with milk, and getting a black coffee,
and an advice from the waiter that you can use any milk or cream
with your black coffee, but no milk or cream served.

Best,
Dima