Subject: Re: libpthread busted?
To: Peter Seebach <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 02/28/2003 16:02:12
On Fri, 28 Feb 2003, Peter Seebach wrote:
> In message <20030228191301.GB18500@yeah-baby.shagadelic.org>, Jason R Thorpe wr
> > > #0 0x4818f337 in kill () from /usr/lib/libc.so.12
> > > #1 0x4819146e in __libc_mutex_unlock () from /usr/lib/libc.so.12
> > > #2 0x481fefa2 in malloc () from /usr/lib/libc.so.12
> >Ah ... is it dynamically-loading libpthread? That does not currently
The reason Jason thinks it doesn't work is that you've bound to a libc
mutex operation, which only happens if NetBSD's libpthread isn't around at
dynamic link time.
> Er. "But it used to work." Or at least, it used to be that, if I build
> all this stuff in pkgsrc, I got the right results.
> I'm not sure whether or not it's actually dynamically loading pthread; this
> crash seems to happen *before* the pth stuff gets involved, although I can't
> be sure.
If that's not a typo, that's a problem. With -current pthreads, you can
ONLY use -current pthreads. You can't mix different thread libraries
What MIGHT be happening is that a program's using pth, not NetBSD's
libpthread. That will be a problem as we have expectations of what
-lpthread does (overrides some weak symbols in libc) that the pth package
mightn't be doing.