On Tue, 29 Oct 2002, Terry Lambert wrote:
> 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".
The point is that with the current setup of the XFree86-4-libraries port,
you don't have any choice, since libX11 links to libXThrStub. This is the
key problem, IMHO. I have a machine running RedHat 8.0 and they don't have
any such thing. On RedHat, libXThrStub doesn't even exist.
All you have to do is create a situation where a shared object that links
to libc_r is loaded after libX11 and the thing breaks into little pieces.
--
Doug Rabson Mail: [EMAIL PROTECTED]
Phone: +44 20 8348 6160
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
