pthread-changes from 1.6 to 1.7?

[Thomas Schlesinger]

Am Donnerstag, 14. September 2006 09:33 schrieb Joerg Sonnenberger:
> 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
> systems.
>
> Joerg

Can this be the cause for kmymoney2 crashing, too?

[..]
[Switching to Process 858, Thread 1]
0x29f070c4 in poll () from /usr/lib/libc.so.6
#0  0x29f070c4 in poll () from /usr/lib/libc.so.6
#1  0x29eb1974 in _thread_kern_sched_state_unlock () from /usr/lib/libc_r.so.5
#2  0x29eb138b in _thread_kern_scheduler () from /usr/lib/libc_r.so.5

Thomas