Hello,

Am Freitag, den 17.10.2014, 21:36 +1100 schrieb Michael:
> 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?

If you are really sure that your whole toolchain is built with musl,
things like that shouldn't happen. My guess would be that there still
is some inconsistency somewhere and a glibc version of pthreads is
loaded before musl. It could help if you'd compile your libraries with
debugging symbols so we could see where (which function and which
version) this happens.

This gthread stuff doesn't seem to be too complicated. It *should*
just generate calls to the corresponding pthread functions, but
obviously here for you it doesn't. Your stack in the __gthread_once
function seems to be corrupted.

Two fishy things:

  - these are static inline functions, so to use this library you have
    to use the same pthread implementation for all compilations of
    application code. If anything in your tool chain goes wrong, your
    screwed.

  - right at the start it seems to rely on certain features of the
    glibc implementation concerning weak symbols.

This seems to be handled with the macros

__GXX_WEAK__ && _GLIBCXX_GTHREAD_USE_WEAK

It could be a starting point to see how they are set and to play at
bit with them.

Jens

-- 
:: INRIA Nancy Grand Est ::: AlGorille ::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536   ::
:: :::::::::::::::::::::: gsm France : +33 651400183   ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::