On Wed, 30 Oct 2002, Doug Rabson wrote:

> On Wed, 30 Oct 2002, Terry Lambert wrote:
> 
> > Daniel Eischen wrote:
> > > > That's bizarre... it's defined in libc_r, so there's no reason for
> > > > the omission in libc.
> > >
> > > I only added stubs that I thought the implementation of libc used
> > > (or would use).
> >
> > Makes sense.
> >
> > Actually, it looks like most of this could be done with macros,
> > including the function definitions, so that we are just dealing
> > with lists; I didn't go that far with it.
> >
> >
> > > > Please find attached a patch that corrects this.
> > >
> > > Patch looks correct.
> >
> > Please commit?  8-).
> 
> Well I made a libc with this patch and rebuilt XFree86-4-libraries without
> libXThrStub but I ran into problems compiling the clients. The clients
> *require* someone in the link to supply the pthread_* symbols and libc.so
> only had _pthread_* symbols. I added some more weak references to libc.so
> but that just gets us back to square one.

I think Terry might be right in suggesting using a macro to automate
all the link and stub generation...

> The problem is that the sawfish configuration tools are written using some
> extensible lisp/scheme thing called rep. The main rep binary links against
> libc.so so that occurs early in the list. Later on stacks of libraries are
> loaded dynamically, some of which depend on libc_r.so. Unfortunately
> libc_r.so is far too late in the list to get a lookin and it dies in
> exactly the same way as before, for the same reason (calling a
> non-functional stub version of pthread_setspecific().

Well, it must have the same problem with Solaris then.  Somehow,
you've got to force it to link libc_r before libc...

--
Dan Eischen


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to