[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/
- Re: [Bug-readline] Linking Shared libreadline with(out) TERMCAP_LIB,
Dmitrii Pasechnik <=