Date: Thu, 24 Jan 2019 12:18:12 +0100 From: Florian Weimer <fweimer@...hat.com> To: musl@...ts.openwall.com Subject: Re: Symbol versioning approximation trips on compat symbols * 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 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). Thanks, Florian
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.