On Fri, 28 Feb 2003, Peter Seebach wrote:

> In message <Pine.NEB.4.33.0302281558440.2258-100000@vespasia.home-net.icnt.net>
> , Bill Studenmund writes:
> >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.
>
> Okay.  I'm not sure how I'd... ldd!
>
> /usr/pkg/bin/perl:
>          -lm.0 => /usr/lib/libm387.so.0
>          -lm.0 => /usr/lib/libm.so.0
>          -lcrypt.0 => /usr/lib/libcrypt.so.0
>          -lc.12 => /usr/lib/libc.so.12

Ok, no pthread.

> >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
> >together.
>
> Or I could just be easily confused; I vaguely recall pthreads and "pth" being
> similar.

They are similar. They are also different. :-) As Nathan said, you can use
one or the other.

> Oh!  I have several packages which claim they "need" pth.  So, let me guess, I
> should delete *those*, too, and nuke the pth package?

Maybe, maybe not. Probably though.

If the package were good about making sure when it said -lpthread it got
pth's libpthread, it's ok. But the linker might get the wrong one, in
which case there's a mess so you should just delete the pth package &
rebuild dependencies.

> >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.
>
> Oh-ho!  Perfect, logical, explanation.  I will try that.

Turns out its wrong, as Nathan indicated. Among other things, pht-pthreads
won't tell libc that NetBSD's libpthread is around. :-)

Take care,

Bill