DragonFly BSD
DragonFly users List (threaded) for 2006-09
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: pthread-changes from 1.6 to 1.7?

From: Joerg Sonnenberger <joerg@xxxxxxxxxxxxxxxxx>
Date: Thu, 14 Sep 2006 09:33:53 +0200
Mail-followup-to: users@crater.dragonflybsd.org

On Wed, Sep 13, 2006 at 01:34:34PM -0700, walt wrote:
> The basic problem is whether an OS uses libpthread or libc_r
> for the threading library.  Unfortunately, I have no idea why
> developers choose one over the other -- maybe someone here could
> 'splain it to us?  I get the feeling that there is a lot of
> history involved in this story.

The basic problem you should be aware of is that loading a thread
library as dependency only works during the initial linking. This is
quite easy to understand when looking e.g. at the stdio locking inside
libc, which is reduced to a nop otherwise.

FreeBSD 4 originally shipped libc_r with included libc and we inherited
that until it was fixed shortly after 1.2 (I think, haven't verified).
For the very same reason, libtool explicitly drops libc_r from shared
object creation calls. -pthread is handled slightly different -- it is
recorded, but doesn't directly affect the linkage. A library can be
used without linking the main program with -pthread as long as they
don't call pthread_create. The patch replaces the hard-coded detection
magic with a test for the *known* values in pkgsrc, but that's of course
not portable and upstream ready. Testing for -pthread as thread linkage
option is a good thing in general though, since it works on a lot of


[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]