Re: Symbol versioning approximation trips on compat symbols

[Rich Felker <dalias@libc.org>]

On Thu, Jan 24, 2019 at 12:18:12PM +0100, Florian Weimer wrote:
> * Szabolcs Nagy:
> 
> > but it turned out to be broken (ifunc resolvers may run before
> > relocations for the extern object are processed), so the symbol
> > was removed (moved to libgcc.a), but a compat symbol (@) was
> > kept around and the ctor of libgcc_s.so.1 still references it.
> 
> I assume we cannot use a hidden alias to eliminate the symbolic
> reference because it is a data symbol, so copy relocations are a
> possibility and with the hidden alias, the constructor would update the
> wrong object?

I believe we had a perfectly workable alternate solution using
something like that, but someone on the upstream side wasn't willing
to change it.

> > i wonder what is the use-case for using a compat symbol without
> > introducing a new default version for the symbol in general?
> 
> A compat symbol can be implemented by a different library, and
> applications can link to the symbol and get it from the new library.
> 
> Mostly it is just for documenting intent, marking the symbol as
> deprecated.  It's still relatively easy to link to the symbol from new
> binaries (even without resorting to dlvsym).

For what it's worth, compat symbols would have let us remove symbols
that shouldn't have been put in musl, such as lchmod (which confuses
broken apps which wrongly expect that, if it exists, it should work)
and perhaps all the LFS64 symbols (which should be present for
binary-compat but not at ld-time so that configure doesn't detect and
try to use them). However, doing it that way would put a symver table
in musl libc.so, resulting in lots of other behaviors we almost surely
don't want. It does shed some light on possible motivations, though, I
think.

Rich