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 <dalias@libc.org>
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