[omniORB] forking and linking with -lpthread

Christof Meerwald cmeerw@web.de
Thu, 28 Mar 2002 23:14:47 +0100


On Thu, 28 Mar 2002 17:55:13 +0100, Eric Marsden wrote:
> I ran into strange problems with omniORB from CVS on Linux 2.4. We
> weren't linking with -lpthread, and calls to fork() in a servant were
> causing the server threads to hang at the point fork() was called (no
> child process was created). Adding the library makes things work as
> expected.
> 
> Does anyone have an idea of what the problem is exactly?

AFAIK, glibc includes some functions optimized for single-threaded programs
(defined as weak symbols) and libpthreads provides the multi-threaded
versions of these functions. Only If you link with pthreads the multi-thread
aware functions are used, otherwise only the single-thread functions are
used.

If you grep the dynamic symbols of glibc for fork
("nm -D /lib/libc.so.6 | fgrep fork") you will get something like:

000a4cb0 W __fork
000a4cb0 T __libc_fork
         w __pthread_atfork
000a4ce0 T __vfork
000a4cb0 W fork
000a4ce0 W vfork

as you can see, __fork is defined as a weak symbol in glibc.


and then do the same with libpthreads:

00008400 T __fork
         U __libc_fork
00008368 T __pthread_atfork
000084c8 T __vfork
00008400 W fork
00008368 T pthread_atfork
000084c8 W vfork

but if you link with libpthreads, __fork is redefined in libpthreads and the
multi-thread aware __fork will be used.


bye, Christof

-- 
http://cmeerw.org                                 JID: cmeerw@jabber.at
mailto cmeerw at web.de