From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6362 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: gthread_once Date: Sat, 18 Oct 2014 12:18:13 +0200 Message-ID: <20141018101813.GB16659@port70.net> References: 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 1413627513 24326 80.91.229.3 (18 Oct 2014 10:18:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 18 Oct 2014 10:18:33 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6375-gllmg-musl=m.gmane.org@lists.openwall.com Sat Oct 18 12:18:27 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 1XfR5f-0001IA-Kl for gllmg-musl@plane.gmane.org; Sat, 18 Oct 2014 12:18:27 +0200 Original-Received: (qmail 25778 invoked by uid 550); 18 Oct 2014 10:18:26 -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 25767 invoked from network); 18 Oct 2014 10:18:25 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Xref: news.gmane.org gmane.linux.lib.musl.general:6362 Archived-At: * 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