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

[Yury Gribov <y.gribov@samsung.com>]

On 04/20/2016 01:19 PM, Pedro Alves wrote:
> On 04/20/2016 10:45 AM, Yury Gribov wrote:
>> On 04/20/2016 12:22 PM, Pedro Alves wrote:
>
>>> - Claim that the symbols may no longer be available in a
>>>     future release.
>>
>> You mean just email respective package maintainers?
>
> I was thinking readline's CHANGES / release notes.
>
> Emailing respective package maintainers / filing bugs with them
> doesn't hurt of course.
>
>>
>>> - Give time for packages to clean themselves up, and propose
>>>     any necessary new replacement APIs.
>>
>> This would require significant expertise in readline though...
>
> The alternative is bless the private symbols as
> public API forever...  Each package owner will know what their
> package needs from readline and why they found a need
> to (ab)use readline private symbols.  I see no way around that.

Guess that's what's going to happen (unless some motivated readline 
maintainer steps in, willing to work with various users on getting rid 
of leaked symbols).

>>> - Optionally, in the release after the next, mark the symbols
>>>     as deprecated with __attribute__((deprecated)), so packages
>>>     that abuse private symbols get a build-time warning.
>>
>> That won't help as these symbols are not present in headers anyway.  All
>> users have their own private declarations.
>
> OK.  Making it a linker warning instead,using ".gnu.warning.SYMBOL"
> sections might still work:
>
>   http://www.airs.com/blog/archives/54

Oh my, this is such a cool feature. I was actually thinking about a 
"Deprecated" attribute for ELF symbols which static/runtime linker could 
use to bark. Pushing such thing to Binutils and GCC would take ages 
though...

> Not sure it's a good idea to raise warnings without alternatives
> already in place though, thus my "Optionally".
>
> Thanks,
> Pedro Alves
>
>
>