Alex Shnitman <[EMAIL PROTECTED]> writes:
> On Sun, 2003-07-13 at 10:49, Gilad Ben-Yossef wrote:
>
> > Can you please post the link command used to generate the binary? did
> > you remember to lni libpthread? because if you didn't you're using the
> > standart fork/exec instead of the thread aware ones from libpthread and
> > this explains what you're seeing.
>
> Gilad, thanks! I was using -lrt instead of -lpthread. -lrt includes the
> timer_* routines, and it also links to libpthread, but apparently
> overrides the functions with some other non-working versions. -lpthread
> works fine.
I'd like to understand the effect if someone is kind enough to provide
an explanation (or confirm my guess below).
On my RH7.3 (glibc-2.2.5-43, gcc-2.96-113, kernel 2.4.20-18.7) librt
has only undefined references to pthread_create. FWIW the results of
/pth created with
gcc -o pth pth.c -lpthread
and
gcc -o pth pth.c -lrt
where pth.c contains the code from your original posting are identical
(modulo pid) on my system (puzzle).
Maybe in the latter case a pthread_create symbol is linked from
libgcc, where it is designated as weak ("w"). I wonder if the linker
simply decides to assign the symbol a zero value with no error in this
case? And then things go haywire at runtime (which is bad) or they
don't (the puzzle above still stands).
--
Oleg Goldshmidt | [EMAIL PROTECTED]
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
