From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6363 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: gthread_once Date: Sat, 18 Oct 2014 11:45:18 -0400 Message-ID: <20141018154518.GE32028@brightrain.aerifal.cx> References: <20141018101813.GB16659@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1413647139 10060 80.91.229.3 (18 Oct 2014 15:45:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 18 Oct 2014 15:45:39 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6376-gllmg-musl=m.gmane.org@lists.openwall.com Sat Oct 18 17:45:34 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 1XfWCB-0001tG-P4 for gllmg-musl@plane.gmane.org; Sat, 18 Oct 2014 17:45:31 +0200 Original-Received: (qmail 19666 invoked by uid 550); 18 Oct 2014 15:45:30 -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 19655 invoked from network); 18 Oct 2014 15:45:30 -0000 Content-Disposition: inline In-Reply-To: <20141018101813.GB16659@port70.net> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:6363 Archived-At: On Sat, Oct 18, 2014 at 12:18:13PM +0200, Szabolcs Nagy wrote: > * Michael [2014-10-18 13:16:52 +1100]: > > > Essentially my plan is to compile my console only app for android but using > > the musl library instead of bionic. Im compling for standard x86_64 linux > > first to see if its viable. My app is plain c++ using wxwidgets (base only) > > and boost threads/system. I compiled these dependencies using CC/CXX/AR etc > > vars set to x86_64-linux-musl-gcc etc... and they compile fine and appear > > to be only linking to musl libraries as i used -v on the compliation and > > watched the directories it pulls in. > > > > Could the pthread_once be something to do with this thread > > http://sourceware-org.1504.n7.nabble.com/PATCH-Provide-pthread-atfork-in-libc-nonshared-a-and-libc-a-td246012.html#a247866 > > > > that's a different glibc specific problem: they have separate > libpthread which makes a lot of things hard so they do various > workarounds > > in your case it seems libstdc++ uses the gthr-posix.h from libgcc > that provides the __gthread_once function which is supposed to call > pthread_once through a weak reference, but the weak ref is 0 > (so uninitialized, eventhough musl have the pthread_once symbol) > > i'd check > > nm libstdc++.a |grep pthread_once > > you should see undefined weak symbols (w) i think > > and then at link time these should resolve to the pthread_once > in libc.a If I understand the explanation of what's going on correctly, it's a huge bug in libstdc++, and exactly the same as the one that's known (and that we've discussed on IRC, etc.) many times in libxml2: https://bugzilla.gnome.org/show_bug.cgi?id=704904 It looks to me like gcc is expecting dynamic-linking-like and/or bloatware-libpthread-like behavior, where if any one of the pthread symbols has a definition, they all do. This is definitely NOT the case with static linking, especially with musl. It's also not the case with glibc, though they have more indirect dependencies that cause a large portion (but not all) of libpthread to be pulled in when you use any one part, and some distros (at least Redhat ones, IIRC) link their libpthread.a with a hack to merge all the modules into one giant .o file inside the .a precisely to work around bugs like this. If I'm correct, just removing all the weak attributes from the gthr-posix.h stuff should fix the bug. Rich