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

[Dmitrii Pasechnik]

On Tue, Apr 23, 2019 at 04:32:21PM -0400, Chet Ramey wrote:
> On 4/23/19 12:41 PM, Dmitrii Pasechnik wrote:
> > 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.
> 
> OK, late followup is better than none, I suppose.
> 
> > 
> >>
> >>> 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.
> 
> Any application that links with curses or termcap is going to have this
> possibility. You can't guarantee that a symbol UP defined in an application
> linked with readline will not override the one in the library.

while it differs from one platform to another (e.g. Solaris' direct
binding would make it totally impossible),  underlinking
prevents meaningful testing and quality assurance---one cannot test
readline for every termcap library that might appear on the box, and
once the tests are done, it's reasonable that the record of the termcap
used is branded onto the library, e.g. in the case of ELF
in the form of NEEDED record, seen by e.g. readelf -d:

$ readelf -d /usr/lib/x86_64-linux-gnu/libreadline.so # patched readline

Dynamic section at offset 0x445b0 contains 26 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libtinfo.so.5]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000000e (SONAME)             Library soname: [libreadline.so.7]
 0x000000000000000c (INIT)               0x14e38
...

as opposed to the unpatched state:

$ readelf -d /tmp/blah/lib/libreadline.so # unpatched

Dynamic section at offset 0x45580 contains 26 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000000e (SONAME)             Library soname: [libreadline.so.8]
 0x000000000000001d (RUNPATH)            Library runpath: [/tmp/blah/lib]
 0x000000000000000c (INIT)               0x150e0
...

> >> 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 :-)
> 
> Maybe, but nobody has reported anything to this point.

As far as I can tell, there are more than this particular 5 y.o. thread
around pointing at this underlinking issue, forcing everyone to patch or
adding `-ltinfo` or whatever to every place readline is linked in. One
can do better than this.

> 
> > 
> >>>> 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.
> 
> TERMCAP_LIB is for the application using readline to use in its Makefile
> for linking. That's how bash uses it, for example.

Makefile or no makefile, there is no need to force extra complexity and 
uncertainty
on the users of readline. Yes, surely, one can add tests to configure to decide
whether readline needs extra termcap libraries explicitly loaded, but it is 
next to
impossible, without running a full-blown testsuite, to find out whether
it must be libtermcap or libtinfo, or libcursesw, just no way (unless it really 
is
recorded in the library itself, e.g. in ELF NEEDED record).

And there are uses of readline where the loading of it is dynamic,
e.g. that's what Python, more precisely, its readline module,` does. And then 
in Python
>>> import readline
leads to an error, and there is really no way to use underlinked
readline.so with python.


> >> 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.
> 
> You're adding an interpretation to --with-curses that is not currently
> there. If that's your goal, and I think it is, that's fine. But I would
> not consider it confusing.
Certainly it is already there:

readline-8.0$ ./configure -h | grep curses
  --with-curses           use the curses library instead of the termcap

clearly says: " --with-curses will give me readline linked with curses",
any other interpretation makes little sense.

Best,
Dima

signature.asc
Description: PGP signature