On Tue, 29 Oct 2002, John Polstra wrote:
> In article <[EMAIL PROTECTED]>,
> Doug Rabson <[EMAIL PROTECTED]> wrote:
> > I just spent a few hours trying to get gnome working on one of my systems,
> > since kde still appears to be completely hosed. Unfortunately, not much of
> > it worked reliably. In particular, all the sawfish preferences applets
> > crash instantly.
> >
> > 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 :-(
>
> When a symbol is defined in multiple libraries, the first library
> wins. That's how it has always been in Unix, for archive libraries
> and for shared libraries.
This is a big problem then since X11.so links to XThrStub.so. This means
that XThrStub will be ahead of libc_r in many situations.
--
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
