Re: Undefined use of weak symbols in gnulib

[Florian Weimer via Libc-alpha <libc-alpha@sourceware.org>]

* 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