Re: Re: gthread_once

[Rich Felker <dalias@libc.org>]

On Sat, Oct 18, 2014 at 12:18:13PM +0200, Szabolcs Nagy wrote:
> * Michael <msbroadf@gmail.com> [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