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: Chet Ramey
Subject: Re: [Bug-readline] Linking Shared libreadline with(out) TERMCAP_LIB
Date: Tue, 23 Apr 2019 16:32:21 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

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.


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

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


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

-- 
``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]