Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pthread_atfork symbol not linked correctly when using glibc #5636

Closed
vicuna opened this issue Jun 5, 2012 · 2 comments

Comments

Projects
None yet
1 participant
@vicuna
Copy link

commented Jun 5, 2012

Original bug ID: 5636
Reporter: Richard Jones
Status: closed (set by @xavierleroy on 2015-12-11T18:04:52Z)
Resolution: fixed
Priority: normal
Severity: minor
OS: Linux
Version: 3.12.1
Fixed in version: 4.00.0+dev
Category: configure and build/install
Monitored by: "Richard Jones"

Bug description

On ppc/ppc64, when you link any bytecode threaded program, you'll get an error:

$ cat test.ml
let _ = Thread.create
$ ocamlc -thread unix.cma threads.cma test.ml -o test
File "test.ml", line 1, characters 0-1:
Error: Error on dynamically loaded library: /usr/lib64/ocaml/stublibs/dllthreads.so: /usr/lib64/ocaml/stublibs/dllthreads.so: undefined symbol: pthread_atfork

In glibc, the pthread_atfork symbol is handled specially -- it is statically linked into programs, unlike other pthread_* symbols which are dynamically linked. To see how this works, examine /usr/lib*/libpthread.so on a glibc system. Notice that it's a linker script which links the program with both libpthread.so.0 (the dynamic library) and libpthread_nonshared.a which is a static library containing just the pthread_atfork symbol.

dllthreads.so (the bytecode standard threads library in otherlibs/systhreads) is currently created like this:

$(MKLIB) -o threads $(BYTECODE_C_OBJS)

which means that it creates an external undefined reference to pthread_atfork:

$ nm dllthreads.so | grep pthread_atfork
U pthread_atfork

Including the static symbol in dllthreads.so (using explicit -lpthread to invoke the linker script) makes the problem go away:

$(MKLIB) -o threads $(BYTECODE_C_OBJS) -lpthread

$ nm dllthreads.so | grep pthread_atfork
0000000000003520 t __pthread_atfork
0000000000003520 t pthread_atfork

(Note that you only see this error on ppc. The x86-64 version of glibc contains a dynamic version of pthread_atfork, which is a bug in glibc!)

For in-depth information, see this thread:

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

and "pthread_atfork on ppc64" here:

https://lists.fedoraproject.org/pipermail/ppc/2012-June/thread.html#1655

Steps to reproduce

See description.

Additional information

http://ryanarn.blogspot.co.uk/2011/07/curious-case-of-pthreadatfork-on.html
https://lists.fedoraproject.org/pipermail/ppc/2012-June/thread.html#1655

@vicuna

This comment has been minimized.

Copy link
Author

commented Jun 5, 2012

@vicuna

This comment has been minimized.

Copy link
Author

commented Jun 8, 2012

Comment author: @xavierleroy

Thanks for the information and the patch, which is now applied in 4.00 branch (r12585) and in trunk (r12586).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.