pthread_atfork on ppc64

[Richard W.M. Jones]

As explained at length here:

http://ryanarn.blogspot.co.uk/2011/07/curious-case-of-pthreadatfork-on.html

on ppc64, 'pthread_atfork' is in a separate static library called
libpthread_nonshared.a, and libpthread.so is a linker script that
links both libpthread.so.0 (dynamically) and libpthread_nonshared.a
(statically).

It's a complete mystery why it does this.  The libpthread_nonshared.a
library also exists on x86-64, but there's an ordinary pthread_atfork
symbol in the regular shared library too.

Anyway ...  The OCaml bytecode compiler relies on being able to create
a shared library which is dlopen(3)-d at run time and should link to
all thread functions.  The shared library is here:

/usr/lib64/ocaml/stublibs/dllthreads.so

However on ppc64, when this is dlopen(3)-d it causes an error because
of the unresolved pthread_atfork symbol (this symbol is used by the
OCaml threads wrapper).  Any threaded OCaml program linked as bytecode
gives the error:

Error: Error on dynamically loaded library: /usr/lib64/ocaml/stublibs/dllthreads.so: /usr/lib64/ocaml/stublibs/dllthreads.so: undefined symbol: pthread_atfork

(This doesn't affect native-compiled OCaml programs).

So I can change OCaml to include the static copy of pthread_atfork in
dllthreads.so, since I guess this library will only be loaded once, so
there should be only one static copy of this function.

But does anyone have any insight in what's going on here?  Why does
this symbol only need to be statically copied into every executable,
but it's only this way on powerpc?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v