[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201123171016.GV1312820@redhat.com>
Date: Mon, 23 Nov 2020 17:10:16 +0000
From: Jonathan Wakely <jwakely@...hat.com>
To: Rich Felker <dalias@...c.org>
Cc: Florian Weimer <fw@...eb.enyo.de>,
Арсений <a@...r0n.science>,
musl@...ts.openwall.com
Subject: Re: Mutexes are not unlocking
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.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
