From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/10253 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Issues when building libcxx libcxxabi with MUSL Date: Thu, 30 Jun 2016 10:58:09 -0400 Message-ID: <20160630145809.GC15995@brightrain.aerifal.cx> References: <87e30e04-a81d-4302-5dd7-0846aa0f711b@codeaurora.org> <1165D9B8-DEDB-4393-B734-3FC1AFFAB46F@gmail.com> <20160622194149.GU10893@brightrain.aerifal.cx> <8836ED26-349A-4701-9D7A-F1D2CF272A24@gmail.com> <20160630133827.GA15995@brightrain.aerifal.cx> <3BEDF5FF-692E-427D-A02C-3950902B9CC7@gmail.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1467298723 27853 80.91.229.3 (30 Jun 2016 14:58:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 30 Jun 2016 14:58:43 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-10266-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jun 30 16:58:30 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1bIdQ8-0005Kq-8R for gllmg-musl@m.gmane.org; Thu, 30 Jun 2016 16:58:24 +0200 Original-Received: (qmail 21898 invoked by uid 550); 30 Jun 2016 14:58:22 -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 21880 invoked from network); 30 Jun 2016 14:58:21 -0000 Content-Disposition: inline In-Reply-To: <3BEDF5FF-692E-427D-A02C-3950902B9CC7@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:10253 Archived-At: On Thu, Jun 30, 2016 at 04:36:09PM +0200, Julien Ramseier wrote: > > > Le 30 juin 2016 à 15:38, Rich Felker a écrit : > > > > Could you cite the specific text you're looking at? The requirement of > > static storage was removed by > > http://austingroupbugs.net/view.php?id=70 but I see nothing allowing > > the use of mutex values or assigning one to another, which as I > > understand it is what the offending libc++ code is doing. > > I'm not sure what you mean by "mutex value". What I mean is any use of an expression of type pthread_mutex_t except an lvalue whose address is taken to pass to one of the pthread_mutex_* functions -- and especially, assignment expressions assigning a value of type pthread_mutex_t to an object of type pthread_mutex_t. > The libcxx mutex class only uses the PTHREAD_MUTEX_INITIALIZER > macro as an initializer for its underlying pthread_mutex member. I don't know modern C++ well enough to evaluate whether that's accurate. But in the old code this looks like use of a mutex value: constexpr mutex() _NOEXCEPT : __m_(_LIBCPP_MUTEX_INITIALIZER) {} Maybe I'm misreading it. > The part of the spec I was referring to is the use of > PTHREAD_MUTEX_INITIALIZER to initialize non-static mutexes, > which is what libcxx did and still do with my patch, but in a different > way to avoid the constexpr issue due to the nested volatile types. If the old code was actually just an initialization but just failing to work for some technical C++ reasons, I'm sorry for the noise. In any case it seems like there's a working fix now. Rich