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=-3.3 required=5.0 tests=MAILING_LIST_MULTI,
	RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham
	autolearn_force=no version=3.4.4
Received: (qmail 22193 invoked from network); 23 Nov 2020 16:59:37 -0000
Received: from mother.openwall.net (195.42.179.200)
  by inbox.vuxu.org with ESMTPUTF8; 23 Nov 2020 16:59:37 -0000
Received: (qmail 24462 invoked by uid 550); 23 Nov 2020 16:59:34 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
List-ID: <musl.lists.openwall.com>
Reply-To: musl@lists.openwall.com
Received: (qmail 24434 invoked from network); 23 Nov 2020 16:59:33 -0000
From: Florian Weimer <fw@deneb.enyo.de>
To: Jonathan Wakely <jwakely@redhat.com>
Cc: Rich Felker <dalias@libc.org>,  =?utf-8?B?0JDRgNGB0LXQvdC40Lk=?=
 <a@saur0n.science>,  musl@lists.openwall.com
References: <1605849917.737458858@f540.i.mail.ru>
	<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>
Date: Mon, 23 Nov 2020 17:59:16 +0100
In-Reply-To: <20201123161907.GT1312820@redhat.com> (Jonathan Wakely's message
	of "Mon, 23 Nov 2020 16:19:07 +0000")
Message-ID: <87zh383t7f.fsf@mid.deneb.enyo.de>
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: [musl] Mutexes are not unlocking

* Jonathan Wakely:

> 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.

Typically, that doesn't work for main programs because the link editor
will resolve weak unexported symbols to zero.  There might not be a
dynamic symbol entry for __pthread_key_create in this case.  Shared
objects are different in this regard.

I think interoperability for these mismatches has to come directly
from the mutex implementation.