Re: [musl] Mutexes are not unlocking

[Jonathan Wakely <jwakely@redhat.com>]

On 23/11/20 11:51 -0500, Rich Felker wrote:
>On Mon, Nov 23, 2020 at 04:19:07PM +0000, Jonathan Wakely wrote:
>> On 23/11/20 09:53 -0500, Rich Felker wrote:
>> >On Mon, Nov 23, 2020 at 11:41:24AM +0000, Jonathan Wakely wrote:
>> >>If the musl libstdc++ removes the use of __gthread_active_p, but code
>> >>compiled against a glibc libstdc++ inlines the __gthread_active_p
>> >>check, then it seems to me that musl (or the musl libstdc++) needs to
>> >>ensure that the inlined __gthread_active_p will return true. It can do
>> >>that by providing a non-weak symbol called __pthread_key_create (the
>> >>symbol won't be called, it just has to exist).
>> >
>> >The target files for -musl tuples disable the hack entirely by adding
>> >t-gthr-noweak and -DGTHREAD_USE_WEAK=0 where appropriate. So there's
>> >no issue here. OP's problem was trying to make glibc-linked binaries
>> >and use them with musl's very limited glibc-ABI-compat capabilities,
>> >which is not recommended; it's only intended as an aid in running
>> >binaryware (esp shared libraries) you can't build/get native versions
>> >of.
>>
>> OK. If supporting that not recommended case does become desirable,
>> defining a __pthread_key_create symbol somewhere should work.
>>
>> Or users might be able to solve it for themselves by creating a tiny
>> shared library that contains nothing but a symbol called
>> __pthread_key_create and LD_PRELOADing that, so that the checks in the
>> binaryware looking for that symbol become true.
>
>My understanding was that only static linking was broken by the weak
>ref hack, so I'm not sure why it's happening to begin with. Is
>libstdc++ actually looking for __pthread_key_create rather than
>pthread_key_create?

Yes. I don't remember why but maybe pthread_key_create exists as a
stub in glibc's libc.so and so __pthread_key_create is used to
**really** detect that libpthread.so is linked in.

>That could explain it since we don't provide the
>former (and as responsibility for making this stuff work is shifted to
>gcompat, gcompat could provide it).

Ah, if you already have a library for glibc-compatibility then yes,
adding __pthread_key_create there would seem to make sense.