* Bruno Haible:
> You write:
>> Dynamic linking with weak symbols is not very well-defined. ...
>> the code will crash if pthread_mutexattr_gettype is ever defined.
>
> 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.
> 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.
> 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. The best we can do is to hide definitions of symbols like
pthread_mutexattr_gettype, therefore masking the existence of those
corrupted code paths (like glibc 2.33 and earlier do).
Thanks for looking into this.
Thanks,
Florian
