From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,URIBL_BLACK autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 24662 invoked from network); 23 Nov 2020 17:18:50 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 23 Nov 2020 17:18:50 -0000 Received: (qmail 8071 invoked by uid 550); 23 Nov 2020 17:18:48 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 1807 invoked from network); 23 Nov 2020 17:10:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1606151425; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Dn6qZXz0/2o3T+WZabMdQZhBspNdx+hYtFXXonJ1LOo=; b=c81ILcGr3HXdS1Q3TVdj5VBPscoO+dJDoyH7egj4Idm3e9pKvU/6nRvGujg2QcTtSXgir0 m4/WPQJLaqqgmZO6ZTw5nyURB/xQaLYgWmysmbO9aDJPh1Uclgt/k7T53kQN4sW44jI9/j pUH3lKEX0aDPonDTKAK1Dg2FuolQ6kg= X-MC-Unique: xCPkJ6ycMV-dTPOHF91kXQ-1 Date: Mon, 23 Nov 2020 17:10:16 +0000 From: Jonathan Wakely To: Rich Felker Cc: Florian Weimer , =?utf-8?B?0JDRgNGB0LXQvdC40Lk=?= , musl@lists.openwall.com Message-ID: <20201123171016.GV1312820@redhat.com> References: <1605941217.735966206@f110.i.mail.ru> <20201121155128.GN534@brightrain.aerifal.cx> <1606070615.957905591@f395.i.mail.ru> <20201122191106.GO534@brightrain.aerifal.cx> <87mtz99owk.fsf@mid.deneb.enyo.de> <20201122192824.GQ534@brightrain.aerifal.cx> <20201123114124.GP1312820@redhat.com> <20201123145329.GU534@brightrain.aerifal.cx> <20201123161907.GT1312820@redhat.com> <20201123165121.GW534@brightrain.aerifal.cx> MIME-Version: 1.0 In-Reply-To: <20201123165121.GW534@brightrain.aerifal.cx> X-Clacks-Overhead: GNU Terry Pratchett X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=jwakely@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Subject: Re: [musl] 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.