From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6354 Path: news.gmane.org!not-for-mail From: Michael Newsgroups: gmane.linux.lib.musl.general Subject: Re: gthread_once Date: Fri, 17 Oct 2014 21:36:56 +1100 Message-ID: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b874afeb0ca0f05059bf128 X-Trace: ger.gmane.org 1413542234 17417 80.91.229.3 (17 Oct 2014 10:37:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 17 Oct 2014 10:37:14 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6367-gllmg-musl=m.gmane.org@lists.openwall.com Fri Oct 17 12:37:09 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Xf4uD-0002Hn-Eb for gllmg-musl@plane.gmane.org; Fri, 17 Oct 2014 12:37:09 +0200 Original-Received: (qmail 15430 invoked by uid 550); 17 Oct 2014 10:37:08 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 15422 invoked from network); 17 Oct 2014 10:37:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=OG1qSIh7BU1LXe2P8RN3L62UJSv7JUTeAHFZ8M/2/5Y=; b=NnOXZa4Oz3PKQ6+jEoT24RfT0V4TG4gZEisLN4x5QyxwkXhZLLtTZoug7gXsxaloVt M5MaGOd3Rv3KJSW5gjv9F+W6efqrBciZH5+yiZXPcAbr2f39G/rdxmBDixdksdGRGbwD h/ffjntF+jifaJwnMK04w5RY3nkvuYKeEMd6ZHadYDMgnChW90RQqEjxzWeAhZXGC19j qNIOUFC90ZUT99FMag5Kl2ZMHkMK6aUcW8H3us0XfBIBLfwaKBHhT+rqw204qwpoELtK gF/uLtJuiRWS+Eyjl1/Vm21+3KnI/XXxS/DNNq0zJhCBzUu/PuXIpgbYYBfhF5Jpbndx /EIg== X-Received: by 10.194.206.106 with SMTP id ln10mr9299968wjc.90.1413542216514; Fri, 17 Oct 2014 03:36:56 -0700 (PDT) Xref: news.gmane.org gmane.linux.lib.musl.general:6354 Archived-At: --047d7b874afeb0ca0f05059bf128 Content-Type: text/plain; charset=UTF-8 I'm not linking to glibc. gthread is a thin wrapper over pthread used by gcc (i.e https://gcc.gnu.org/onlinedocs/libstdc++/manual/ext_concurrency_impl.html). It seems my problem is related to this: http://www.riscos.info/pipermail/gcc/2008-July/004525.html I have compiled g++ toolchain using musl-1.1.5 Is this a bug in musl or do i need to turn off the _GTHREAD in the libstdc++ library? ------------------------------------------------------------------ Hi, Am Dienstag, den 14.10.2014, 17:07 +1100 schrieb Michael: > I have compiled my app using musl entirely statically however when it > is run on initialization it crashes with the attached stacktrace under > x86_64. Is this because the local stuff in musl is not fully > finished? > > > Program received signal SIGSEGV, Segmentation fault. > 0x0000000000000000 in ?? () > (gdb) bt > #0 0x0000000000000000 in ?? () > #1 0x00000000006ccecf in __gthread_once () > #2 0x00000000006cd285 in std::locale::_S_initialize() () > #3 0x00000000006cd012 in std::locale::locale() () > #4 0x0000000000683614 in std::basic_streambuf std::char_traits >::basic_streambuf() () > #5 0x00000000006ae590 in __gnu_cxx::stdio_sync_filebuf std::char_traits >::stdio_sync_filebuf(_IO_FILE*) () > #6 0x0000000000684beb in std::ios_base::Init::Init() () > #7 0x00000000004021ee in > _GLOBAL__sub_I__ZN9wxPrivate18GetUntypedNullDataEv () > #8 0x00000000006f5056 in __do_global_ctors_aux () > #9 0x000000000040012b in _init () > #10 0x0000000000000000 in ?? () This looks as if you are using the native C++ lib, and this is using internal stuff from glibc under the hood. In particular, here it seems to be using glibc's implementation of pthread_once to initialize things. Not surprising that this doesn't work. Jens --047d7b874afeb0ca0f05059bf128 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm not linking to glibc. gthread is a thin wrapp= er over pthread used by gcc (i.e https://gcc.gnu.org/onlinedocs/= libstdc++/manual/ext_concurrency_impl.html).

I= t seems my problem is related to this:


I have compiled g++ toolchain using musl-1.1.5

I= s this a bug in musl or do i need to turn off the _GTHREAD in the libstdc++= library?
-------------------------------------------------------= -----------
=
Hi,

Am Dienstag, den 14.10.2014, 17:07 +1100 schrieb Michael:
> I have compiled my app using musl entirely statically however when it
> is run on initialization it crashes with the attached stacktrace under
> x86_64.  Is this because the local stuff in musl is not fully
> finished?
>=20
>=20
> Program received signal SIGSEGV, Segmentation fault.
> 0x0000000000000000 in ?? ()
> (gdb) bt
> #0  0x0000000000000000 in ?? ()
> #1  0x00000000006ccecf in __gthread_once ()
> #2  0x00000000006cd285 in std::locale::_S_initialize() ()
> #3  0x00000000006cd012 in std::locale::locale() ()
> #4  0x0000000000683614 in std::basic_streambuf<char,
> std::char_traits<char> >::basic_streambuf() ()
> #5  0x00000000006ae590 in __gnu_cxx::stdio_sync_filebuf<char,
> std::char_traits<char> >::stdio_sync_filebuf(_IO_FILE*) ()
> #6  0x0000000000684beb in std::ios_base::Init::Init() ()
> #7  0x00000000004021ee in
> _GLOBAL__sub_I__ZN9wxPrivate18GetUntypedNullDataEv ()
> #8  0x00000000006f5056 in __do_global_ctors_aux ()
> #9  0x000000000040012b in _init ()
> #10 0x0000000000000000 in ?? ()

This looks as if you are using the native C++ lib, and this is using
internal stuff from glibc under the hood. In particular, here it seems
to be using glibc's implementation of pthread_once to initialize things=
.

Not surprising that this doesn't work.

Jens
--047d7b874afeb0ca0f05059bf128--