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

[Yury Gribov]

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