Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 30 Oct 2002 22:02:13 +0000 (GMT)
From:      Doug Rabson <dfr@nlsystems.com>
To:        Daniel Eischen <eischen@pcnet1.pcnet.com>
Cc:        Terry Lambert <tlambert2@mindspring.com>, <current@FreeBSD.ORG>
Subject:   Re: [PATCH: libc]Re: gnome on current
Message-ID:  <20021030220141.E22480-100000@herring.nlsystems.com>
In-Reply-To: <Pine.GSO.4.10.10210301607490.13673-100000@pcnet1.pcnet.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 30 Oct 2002, Daniel Eischen wrote:

> 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...

The only way I can see to do that is to link libX11, libXt and friends
against libc_r.

-- 
Doug Rabson				Mail:  dfr@nlsystems.com
					Phone: +44 20 8348 6160



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021030220141.E22480-100000>