Doug Rabson wrote: > On investigating one of the crashes more carefully, I discovered that all > calls to pthread_*() were being resolved to stubs in libXThrStub.so in > spite of the fact that libc_r was also loaded. This caused problems for > e.g. flockfile which failed to initialise its mutex (uthread_mutex.c's > init_static calls pthread_mutex_init instead of _pthread_mutex_init and > ends up in libXThrStub). After working around that, I had more fun where > one of the gnome libs tried to call pthread_getspecific(). > > Why isn't the linker resolving these symbols against the ones in libc_r? > For some reason, libc_r defines them weakly so they get resolved by the > first weak definition in the list of libs, which in this case is > libXThrStub :-(
So that people who know what they are doing can implement their own versions of the code do in.strument things like "open". Unfortunately, the people who wrote libXThrStub.so apparently didn't know what they were doing... Or, more likely, you are not supposed to be linking against library at all, if you have a working threads library... I feel pretty safe guessing that, given that it's name seems to le "X Threads Stub Library". -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
