Bug 145941 - pthread_atfork symbol weird behavior
pthread_atfork symbol weird behavior
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2005-01-24 05:28 EST by mathieu lacage
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-01-24 05:36:34 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description mathieu lacage 2005-01-24 05:28:29 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
Gecko/20041020 Epiphany/1.4.4

Description of problem:
references to the pthread_atfork symbol seem to behave a bit
differently from references to other pthread functions. It seems that
pthread_atfork symbols are not correctly resolved upon link time.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
I build a shared library out of a set of PIC object files, some of
which reference the pthread_atfork symbol.

My shared library is built with the following command line:

cc -lpthread -ldl -shared -o bin/libprofiler/libprofiler.so
bin/libprofiler/manager.o bin/libprofiler/record.o -Lbin/libdebug

Once it is built, I run readelf:
[mlacage@chronos profiler]$ readelf -s
bin/libprofiler/libprofiler.so|grep atfork
    71: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND pthread_atfork
   142: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND pthread_atfork

At this point, I am a bit puzzled by the NOTYPE flag of pthread_atfork
as compared by the output for pthread_create:
[mlacage@chronos profiler]$ readelf -s
bin/libprofiler/libprofiler.so|grep pthread_create
    26: 00000000   387 FUNC    GLOBAL DEFAULT  UND
pthread_create@GLIBC_2.1 (4)
    97: 00000000   387 FUNC    GLOBAL DEFAULT  UND

Actual Results:  
Ok, so, once the shared dynamic library is built, I link a program
which does not use pthreads with this library. The command-line I use is:
[mlacage@chronos profiler]$ cc -lprofiler -Wl,-rpath,bin/libprofiler
-Lbin/libprofiler -ldl   bin/test/test-profiler.o   -o
bin/libprofiler/libprofiler.so: undefined reference to `pthread_atfork'
collect2: ld returned 1 exit status

Which obviously fails.

Expected Results:  Of course, at this point, I can easily add a
-lpthread argument to the link line for my application but I get the
feeling this should not be needed and the dependency of libprofiler.so
towards libpthread.so should be enough. i.e., the link of my
application should not fail without the -lpthread.

Additional info:
Comment 1 Jakub Jelinek 2005-01-24 05:36:34 EST
You are linking the shared library incorrectly.
cc -lpthread -ldl -shared -o bin/libprofiler/libprofiler.so
bin/libprofiler/manager.o bin/libprofiler/record.o -Lbin/libdebug -ldebug-pic

Both -lpthread and -ldl must come after the object files (or .a libraries) that
use them on the link line.
libpthread.so is a linker script that sources in a small .a library and a shared
library.  If doesn't come up after the objects that use the pthread_* etc.
interfaces, although you link the shared library against libpthread.so.0,
you don't link in libpthread_nonshared.a (unless you surround almost everything
on the command line between -Wl,--start-group and -Wl,--end-group,
so that .a libs are searched repeatedly).
pthread_atfork is defined in libpthread_nonshared.a, so that's why things don't
work as expected for you.  Simply move -lpthread -ldl to the end of cmdline
and it will DTRT.

Note You need to log in before you can comment on or make changes to this bug.