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
