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 Runing file against my binary is: ./vhui: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, not stripped If i run readelf -hld: ELF Header: Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: EXEC (Executable file) Machine: Advanced Micro Devices X86-64 Version: 0x1 Entry point address: 0x403309 Start of program headers: 64 (bytes into file) Start of section headers: 14776944 (bytes into file) Flags: 0x0 Size of this header: 64 (bytes) Size of program headers: 56 (bytes) Number of program headers: 4 Size of section headers: 64 (bytes) Number of section headers: 28 Section header string table index: 25 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align LOAD 0x0000000000000000 0x0000000000400000 0x0000000000400000 0x0000000000417b4c 0x0000000000417b4c R E 200000 LOAD 0x0000000000417b50 0x0000000000a17b50 0x0000000000a17b50 0x0000000000014b98 0x0000000000037168 RW 200000 TLS 0x0000000000417b50 0x0000000000a17b50 0x0000000000a17b50 0x0000000000000000 0x0000000000000018 R 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RW 10 Section to Segment mapping: Segment Sections... 00 .init .text .fini .rodata .eh_frame .gcc_except_table 01 .ctors .dtors .jcr .data.rel.ro .got .got.plt .data .bss 02 .tbss 03 There is no dynamic section in this file. ---------- Forwarded message ---------- > From: Rich Felker > To: musl@lists.openwall.com > Cc: > Date: Fri, 17 Oct 2014 08:10:48 -0400 > Subject: Re: [musl] 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 > >