bug-readline
[Top][All Lists]
Advanced

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

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


From: Dmitrii Pasechnik
Subject: Re: [Bug-readline] Linking Shared libreadline with(out) TERMCAP_LIB
Date: Tue, 23 Apr 2019 10:44:27 +0100
User-agent: Mutt/1.9.1 (2017-09-22)

Dear all,
I'd like to raise this issue: "not overlinking"
policy for the shared library, which just leads to proliferation of patches for 
readline,
and ignoring --with-curses if termcap is available.
(see below for details; I edited out and marked by [] some extras not needed)

On Tue, Apr 15, 2014 at 04:46:14PM -0400, Chet Ramey wrote:
> On 4/11/14, 4:11 PM, Дилян Палаузов wrote:
> > when I do ./configure --with-curses the TERMCAP_LIB Makefile variable is
> > filled with -lcurses, and when I do ./configure --without-curses,
> > TERMCAP_LIB is -ltermcap .
> 
> OK, -ltermcap is the default.  The readline configure process will use that
> if --with-curses isn't supplied and the configure macro that looks for a
> ncurses/curses/termlib/termcap library comes up empty.
> > 
> > In terms of support/shobj-conf, my system is "linux-gnu-gcc-unknown", so
> > the case "linux*-*|gnu*-*|k*bsd*-gnu-*|freebsd*-gentoo" on line 127 is 
> > called.
> > 
> > My SHLIB_LIBS is empty, because only on cygwin* and mingw* TERMCAP_LIB is
> > added to SHLIB_LIBS .
> 
> Because Unix systems allow the calling application to supply values for the
> undefined BC, PC, and UP symbols, and Windows traditionally did not.
[ some libhistory details, not important here ]
> 
> > On the other side, under Linux, shlib/libreadline is liked with:
[ details omitted ]
> > -> without passing TERMCAP_LIB, which leads to undefined symbols:
[ a list of symbols, including UP]
> Correct.  Readline does not `overlink'; the application linking with
> readline chooses which library to link with to satisfy the termcap library
> symbols.

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.
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)

So this "not overlinking" simply results in everyone patching readline
(the project I am involed in, sagemath.org, also patches readline, see
https://github.com/sagemath/sage/blob/master/build/pkgs/readline/patches/0002-ltinfo.patch)

> 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.
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'd be glad to supply patches for these two related issues.

Best,
Dima
http://users.ox.ac.uk/~coml0531/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]