[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