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, 30 Apr 2019 17:52:20 +0100
User-agent: Mutt/1.11.4 (2019-03-13)

On Wed, Apr 24, 2019 at 08:59:42AM -0400, Chet Ramey wrote:
> On 4/24/19 5:01 AM, Dmitrii Pasechnik wrote:
> 
> >>>>> 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:
> 
> I'm skeptical of this reasoning, but let's see the patches and see how
> it goes.

Few questions first:

1) Can TERMCAP_DEP be removed? It is not used anywhere in readline
source, as far as I can tell.

2) Would a rewrite of BASH_CHECK_LIB_TERMCAP using AC_SEARCH_LIBS be
acceptable?

3) What is the reason of hard-coding SHLIB_LIBS='-lncurses' on
OSX/Darwin? Can we let configure to figure it out (it will be in TERMCAP_LIB)?

4) "./lib/termcap/libtermcap.a" is something never built by readline,
although TERMCAP_LIB is being assigned this value sometimes, and there
is a check whether TERMCAP_LIB equals this seemingly random value.
Was it meant to be a sub-module?

5) it's not possible to build examples if configure was run with
"--disable-static" - indeed, examples always expect TERMCAP_LIB to be a
static library. This appears to be a bug.

Thanks,
Dima

> 
> 
> >>> 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.
> 
> Send your patches along and let's take a look.
> 
> 
> -- 
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>                ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRU    address@hidden    http://tiswww.cwru.edu/~chet/
> 






reply via email to

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