Re: Re: gthread_once

[Szabolcs Nagy <nsz@port70.net>]

* Rich Felker <dalias@libc.org> [2014-10-18 11:45:18 -0400]:
> 
> 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.

yes this is the bug

it turns out gthr-posix.h decides if there are threads
if pthread_cancel is present (weak ref is non-null)
(on glibc it checks pthread_key_create and on bionic it
checks pthread_create)

if there is no pthread_cancel then libstdc++ will assume
no threads and __gthread calls fail (eg iostream locks
are skipped, in call_once a system_error is thrown)

if there is pthread_cancel then a __gthread_something call
will call pthread_something and if that is otherwise
unreferenced it will crash (in case of static linking)

example that crases here whit -static:

#include <iostream>
#include <pthread.h>
int (*f)(pthread_t) = pthread_cancel;
int main()
{
	std::cout << "";
}

possible workaround: create a .o that references all
pthread_* functions and link it into your app
(this is the bloatware-libpthread solution until libstdc++ is fixed)