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
