[Top][All Lists]

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

Re: [Bug-readline] [PATCH] Enable visibility annotations

From: Pedro Alves
Subject: Re: [Bug-readline] [PATCH] Enable visibility annotations
Date: Fri, 22 Apr 2016 16:15:53 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1

On 04/22/2016 04:09 PM, Yury Gribov wrote:
> On 04/22/2016 05:51 PM, Pedro Alves wrote:

>> I think the visibility patches raise a question that should
>> be considered:
>> Does readline still want to keep these historical "rl_" symbols,
>> even those that we hadn't found any program is using (at
>> least yet) ?
>> Because I think that if we hide them with private visibility,
>> then that effectively is the same thing as removing them
>> for dynamic links.  However, if we don't remove them, then we
>> end up with the inconsistency where a link with dynamic
>> libreadline.so fails, while a link with static libreadline.a succeeds.
>> It seems to me that readline should either:
>>   - completely delete old undocumented backwards compatibility symbols,
>>     or,
>>   - mark them public.
>> Leaving them defined, but marked private leads to the dynamic
>> vs static inconsistency mentioned above.
> I'm afraid this inconsistency is inevitable. Static libs are mere
> archives and do not have any mechanism for visibility control. They'll
> always be leaking internal symbols and there is not workaround for that
> (well, except for marking symbols static or removing them alltogether
> which is obviously not always possible).

That's my point -- the inconsistency _is not_ inevitable -- if we're
making them private, them programs won't be able to use them anyway, so
might as well remove them altogether.  Or at least rename them
to "_rl_" prefix.

Pedro Alves

reply via email to

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