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.6 required=5.0 tests=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 24719 invoked from network); 23 Nov 2020 17:19:06 -0000
Received: from mother.openwall.net (195.42.179.200)
  by inbox.vuxu.org with ESMTPUTF8; 23 Nov 2020 17:19:06 -0000
Received: (qmail 9875 invoked by uid 550); 23 Nov 2020 17:19:04 -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 9846 invoked from network); 23 Nov 2020 17:19:03 -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: <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>
	<20201123171016.GV1312820@redhat.com>
Date: Mon, 23 Nov 2020 18:18:47 +0100
In-Reply-To: <20201123171016.GV1312820@redhat.com> (Jonathan Wakely's message
	of "Mon, 23 Nov 2020 17:10:16 +0000")
Message-ID: <87o8jo3saw.fsf@mid.deneb.enyo.de>
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: [musl] Mutexes are not unlocking

* Jonathan Wakely:

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

There's no pthread_key_create in libc.  Roland actually added a
comment why __pthread_key_create is used:

+/* For a program to be multi-threaded the only thing that it certainly must
+   be using is pthread_create.  However, there may be other libraries that
+   intercept pthread_create with their own definitions to wrap pthreads
+   functionality for some purpose.  In those cases, pthread_create being
+   defined might not necessarily mean that libpthread is actually linked
+   in.

I believe the Boehm/Demers/Weiser garbage collector used to be one of
these libraries.