Re: Undefined use of weak symbols in gnulib

[Bruno Haible]

Hi Florian,

Thank you for the details.

> > In which situations will it crash?
> >
> >   (a) when the code is in an executable, that gets linked with '-lpthread'
> >       and that does not use dlopen()?
> 
> The pthread_mutexattr_gettype is defined, but also pthread_once and the
> weak symbols, so there is no problem because the link editor doesn't do
> funny things.
> 
> >   (b) when the code is in an executable, that gets linked WITHOUT
> >       '-lpthread' and that does not use dlopen()?
> 
> Yes, it will crash or behave incorrectly on most architectures *if*
> pthread_mutexattr_gettype becomes available for some reason.
> 
> >   (c) when the code is in an executable, that gets linked WITHOUT
> >       '-lpthread' and that does a dlopen("libpthread.so.X")?
> 
> This will probably work because pthread_mutexattr_gettype is not rebound
> to the definition.

So, in the normal cases (link with '-lpthread', link without '-lpthread',
and even with dlopen()), everything will work fine. The only problematic
case thus is the the use of LD_PRELOAD. Right?

I think few packages in a distro will be affected. And few users are
using LD_PRELOAD on their own, because since the time when glibc
started to use 'internal' calls to system calls where possible, there
are not a lot of uses of LD_PRELOAD that still work.

> > Under which conditions will it crash?
> >
> >   ($) when the executable was built before glibc 2.34 and is run
> >       with glibc 2.34 ?
> 
> Yes.
> 
> >   (%) when the executable is built against glibc 2.34 and is run
> >       with glibc 2.34 ?
> 
> No.  glibc 2.34 will behave as if an implicit -lpthread is present on
> the linker program line.

Good. This means a bullet-proof way for a distro to avoid the problem
is to "rebuild the world" after importing glibc 2.34.

> > And if it crashes, will setting the environment variable LD_DYNAMIC_WEAK [1]
> > avoid the crash?
> 
> No, it's unrelated.  The crash or other undefined behavior is a
> consequence of actions of the link editor and cannot be reverted at run
> time.

In other words, the problem is that
  - there are some/many binaries out there, that were produced by an 'ld'
    that did not anticipate the changes in glibc 2.34, and
  - these binaries have a problem not when run directly, but only when
    run with LD_PRELOAD.

Right?

Bruno