From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11065 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: No definition of PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP in musl Date: Mon, 20 Feb 2017 12:03:03 -0500 Message-ID: <20170220170303.GR1520@brightrain.aerifal.cx> References: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1487610240 6678 195.159.176.226 (20 Feb 2017 17:04:00 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 20 Feb 2017 17:04:00 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-11080-gllmg-musl=m.gmane.org@lists.openwall.com Mon Feb 20 18:03:55 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1cfrNQ-0001QF-WA for gllmg-musl@m.gmane.org; Mon, 20 Feb 2017 18:03:53 +0100 Original-Received: (qmail 28517 invoked by uid 550); 20 Feb 2017 17:03:56 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 28375 invoked from network); 20 Feb 2017 17:03:18 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:11065 Archived-At: On Mon, Feb 20, 2017 at 03:22:41PM +0000, Raphael Cohn wrote: > Hi, > > Whilst trying to compile ReOpenLDAP (https://github.com/ReOpen/ReOpenLDAP), > a fork of OpenLDAP, I'm running into a wall. Some of the code wants a > definition of PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP. musl doesn't define > this; I suspect this is a non-portable glibc extension in pthread.h. Does > any one have any ideas how I might workaround this? Is there an alternative > construction that the code could use? > > Any help gladly appreciated. This omission is intentional; the layout of pthread objects is kept opaque so that it's free to change and we don't get locked into a layout that turns out to be bad, like what happened to glibc -- they ran out of space for doubly-linked-list pointers needed for robust mutexes, so they use a singly linked list and unlock is O(n) where n is the number of mutexes locked! This also means we can't duplicate the glibc layout (because it was bad) so from an interest of partial ABI compatibility, it's better to just say "these non-portable extension initializers are not supported and don't work" than to have our own mismatching definitions for them. To fix the issue, you need to use pthread_once to initialize the recursive mutex on first use if it has static storage duration. If it's allocated or automatic, just initialize it at the time of creation, before any other threads can be aware of its existence. Rich