[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160630131546.GC19691@port70.net>
Date: Thu, 30 Jun 2016 15:15:47 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: Issues when building libcxx libcxxabi with MUSL
* Julien Ramseier <j.ramseier@...il.com> [2016-06-30 14:50:14 +0200]:
> > Le 22 juin 2016 à 21:41, Rich Felker <dalias@...c.org> a écrit :
> >
> > On Wed, Jun 22, 2016 at 09:38:17PM +0200, Julien Ramseier wrote:
> >> Hi Zhao,
> >>
> >> Not sure how you did build llvm-libcxx, but the only issue I encountered myself is
> >> the use of PTHREAD_MUTEX_INITIALIZER in libcxx include/__mutex_base.
> >> musl uses volatile types in its pthread_mutex_t struct and C++11 does not allow them
> >> with constexpr member initializers. This rule has been relaxed in C++14.
> >
> > Note that the code using them is still formally/conceptually buggy.
> > POSIX does not permit using these initializers as values. They can
> > only be used as initializers for objects with static storage duration.
> > A "mutex value" makes no sense; mutexes are objects not values.
>
> Actually the latest POSIX spec allows it.
> See http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_mutex_init.html <http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_mutex_init.html>
>
yes, the changelog says
POSIX.1-2008, Technical Corrigendum 1, XSH/TC1-2008/0460 [70,428] is applied.
so the semantics changed in 2013
http://austingroupbugs.net/view.php?id=70
> A workaround for the C++11 constexpr issue should land soon in libcxx trunk.
> http://reviews.llvm.org/D21637 <http://reviews.llvm.org/D21637>
>
note that without pthread_mutex_destroy it may leak resources.
(in practice this e.g. matters on freebsd see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71684
on musl this is not an issue)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
