Re: Undefined use of weak symbols in gnulib

[Florian Weimer <fweimer@redhat.com>]

* Bruno Haible:

>> I spent today on coming up with a workaround in glibc.
>
> These are the workarounds I can see:
>   - Delay the planned changes in glibc by 5 years or so, to minimize
>     the number of binaries out there that would crash. (Probably not what
>     you want.)

Nah, those binaries won't go away in just five years.

>   - Change glibc's ld.so to deal with the binaries that are out there
>     and that have been produced by existing binutils (with or without the
>     patches that H.J. Lu listed).

This is what I've tried to implement:

  [RFC] elf: Implement filtering of symbols historically defined in libpthread
  <https://sourceware.org/pipermail/libc-alpha/2021-April/125564.html>

>   - Play tricks with the preprocessor, such as
>     '#define pthread_create pthread_create_in_libc'. (Probably not POSIX
>     compliant.)

It doesn't solve the problem, even for new binaries.

>   - Make use of symbol versioning. Symbol versioning was invented to
>     allow making big changes to libc without breaking binary backward
>     compatibility. (I don't know about the interplay between weak and
>     versioned symbols.)

If the symbol is weak and undefined at build time, there is no symbol
version attached to it.  My patch uses that to make sure the filtering
does not happen on the fast path (because symbols bound to libc.so.6
usually have versions), but I don't think symbol versioning is all that
useful in this context.

Thanks,
Florian