Re: Evolution of ELF symbol management

[Joseph Myers <joseph at codesourcery dot com>]

Further consideration of the __libc_* approach:

There are some cases that should never need public aliases: (a) ISO C90 
functions (no aliases needed unless called from macros defined in system 
headers - such macros should properly call C90 functions by aliases in 
case they are shadowed by local variables in the function calling the 
macro; the function names are reserved with file scope / external linkage, 
but not as local variable names); (b) obsolete functions (even if we still 
support linking with a deprecated function because it's in an older 
standard we support, we could say namespace-clean use of it isn't 
supported); (c) if multiple public functions are or should be aliased to 
each other, e.g. for long double = double, we could have just one __libc_* 
alias between them.

> Maybe we need to take a step back and ask ourselves if we should use symbol
> versioning to address this.  The two blockers I know of are purely static
> links, and the design decision (no doubt for backwards compatibility) to
> interpose versioned symbols with unversioned symbols. The latter is difficult
> to address, but if we could make the change somehow, it would enable a nice
> performance boost in the dynamic linker, too.  But it certainly looks like
> that for the static link case, we only have the header files we can tweak to
> achieve what we want.

And symbol versioning cannot help with the API issue of C++ compilations 
being forced to use _GNU_SOURCE because much of the libstdc++ 
implementation is in the headers and wants to use libc features outside 
the libc subset defined in the C++ standard.  That requires public API 
aliases for lots of functions (maybe for constants, types etc. as well).

-- 
Joseph S. Myers
joseph@codesourcery.com