Should we support (not use, support) symbol versioning?

Should we support (not use, support) symbol versioning?

[Rich Felker]

At present musl's dynamic linker does not support symbol versioning.
It always resolved all symbol lookups to the same (usually this means
latest) version ld would resolve them to, and ignores all
compatibility symbols. This is breaking a new hack in libgcc_s.so
that's going to affect us with new GCC versions.

We can't just outright honor versions like glibc does because of ABI
compat: we want glibc-linked apps/libs, which are referencing all
sorts of versioned symbols from glibc, to have those references
satisfied by the unversioned symbols in musl.

What we could possibly do, however, is honor the version requested
whenever the library being searched has version information. This
would allow third-party libraries that want to use versioning to do so
while also allowing unversioned libraries to satisfy any program or
library using them (and work correctly as long as it's using the
latest version API, just like now). However I'm mildly concerned that
symbol version tables could get introduced into libraries that don't
want them (including into libc.so) which would then horribly break
things, e.g. if any of libgcc.a's symbols were versioned (in principle
this should not happen, because they're all supposed to be hidden, but
I'm not really happy relying on that).

If that doesn't seem viable, there are some hacks we could do to fix
libgcc_s.so, or we could try to get gcc to build it without the
version hacks on musl targets, but I don't know how that would go.

None of this changes the reasons why symbol versioning is a horrible
mistake/misdesign and should not be used for anything; it's just a
matter of trying to keep things from breaking where others are using
it...

Rich

Re: Should we support (not use, support) symbol versioning?

[Rich Felker]

On Sat, May 09, 2015 at 09:03:59PM -0400, Rich Felker wrote:
> What we could possibly do, however, is honor the version requested
> whenever the library being searched has version information. This
> would allow third-party libraries that want to use versioning to do so
> while also allowing unversioned libraries to satisfy any program or
> library using them (and work correctly as long as it's using the
> latest version API, just like now). However I'm mildly concerned that
> symbol version tables could get introduced into libraries that don't
> want them (including into libc.so) which would then horribly break
> things, e.g. if any of libgcc.a's symbols were versioned (in principle
> this should not happen, because they're all supposed to be hidden, but
> I'm not really happy relying on that).

This risk is eliminated just by adding ldso.versym=0; after
decode_dyn(&ldso) in the dynamic linker code, to ensure that any
version tables that happen to creep into libc.so/ldso are ignored.

Rich

Re: Should we support (not use, support) symbol versioning?

[Рысь]

On Sat, 9 May 2015 22:18:38 -0400
Rich Felker <dalias@libc.org> wrote:

> On Sat, May 09, 2015 at 09:03:59PM -0400, Rich Felker wrote:
> > What we could possibly do, however, is honor the version requested
> > whenever the library being searched has version information. This
> > would allow third-party libraries that want to use versioning to do
> > so while also allowing unversioned libraries to satisfy any program
> > or library using them (and work correctly as long as it's using the
> > latest version API, just like now). However I'm mildly concerned
> > that symbol version tables could get introduced into libraries that
> > don't want them (including into libc.so) which would then horribly
> > break things, e.g. if any of libgcc.a's symbols were versioned (in
> > principle this should not happen, because they're all supposed to
> > be hidden, but I'm not really happy relying on that).
> 
> This risk is eliminated just by adding ldso.versym=0; after
> decode_dyn(&ldso) in the dynamic linker code, to ensure that any
> version tables that happen to creep into libc.so/ldso are ignored.
> 
> Rich

Symbol versions were so evil that enforced me to get rid all of them by
patching binutils' ld not to support them anymore and every package
which fails to build without them. I even have a small base of patches
for every package that happen to enforce them. And there are not many
of them. No breackage occured in this area after changes.

With glibc binaries however not such a nice picture. Simple ones which
rely not on glibc's internals probably are worked fine. An advanced ones
I happen to work with (nvidia drivers are example) crashed at end when
program called exit(), working fine before that. For that little time I
instead used another strategy: moved all glibc legacy runtime into
chroot with glibc. Now I cannot reproduce this anymore: no such system
exists today.

I rather think you should not even try to support these. Maybe musl can
became the competing libc which will force such recovery changes
someday.

Re: Should we support (not use, support) symbol versioning?

[u-wsnj]

On Sat, May 09, 2015 at 09:03:59PM -0400, Rich Felker wrote:
> This is breaking a new hack in libgcc_s.so
> that's going to affect us with new GCC versions.

I try to avoid dependencies on newer gcc versions so hopefully
will not be affected. In any case I'd prefer this to be fixed
somewhere else, instead of adding a workaround to musl.

> None of this changes the reasons why symbol versioning is a horrible
> mistake/misdesign and should not be used for anything; it's just a
> matter of trying to keep things from breaking where others are using
> it...

Thanks for the clarification, I was becoming worried otherwise.

Rune