Date: Fri, 17 Oct 2014 08:10:48 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: Re: gthread_once On Fri, Oct 17, 2014 at 01:42:23PM +0200, Jens Gustedt wrote: > 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 sounds unlikely. He's static linking, so there is no separate loading of libraries, but even if there were, musl's dynamic linker refuses to load a library named libpthread.*. Still, I think it would be helpful to see some indication of whether the binary is actually a static binary that was created correctly. The output of the "file" utility run on it, and possibly the output of readelf -hld or even full readelf -a (although the latter might reveal a lot about the program and be big). > 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. It looks like it called a function via a function pointer that happened to be null. > 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. These sound problematic, but if there's something wrong here, I'd be surprised that we haven't seen failures before. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.