Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 31 Oct 2002 09:31:26 -0500 (EST)
From:      Daniel Eischen <eischen@pcnet1.pcnet.com>
To:        Doug Rabson <dfr@nlsystems.com>
Cc:        ak03@gte.com, tlambert2@mindspring.com, current@FreeBSD.ORG
Subject:   Re: [PATCH: libc]Re: gnome on current
Message-ID:  <Pine.GSO.4.10.10210310926070.27891-100000@pcnet1.pcnet.com>
In-Reply-To: <20021031093249.T36855-100000@herring.nlsystems.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 31 Oct 2002, Doug Rabson wrote:

> On Thu, 31 Oct 2002, Alexander Kabaev wrote:
> 
> > On Wed, 30 Oct 2002 22:25:12 -0500 (EST)
> > Daniel Eischen <eischen@pcnet1.pcnet.com> wrote:
> >
> > > > If last weak will win, the normal case when Xthrstub is loaded
> > > > _after_ libc_r will break. The only way to really fix this is to
> > > > export pthread_ symbols as strong in libc_r. Exporting them as weak
> > > > sounds like is a mistake which should be fixed.
> > >
> > > I disagree.  See Solaris 6, 7, 8 & 9 for an example.
> > >
> > Cool. Then let's be consistent and follow Solaris all the way. Libc on
> > Solaris provides full set of pthread_? functions which in turn call
> > weakly defined _pthread_?? counterparts. libpthread in turn provides
> > strong definitions for _pthread_??.
> >
> > Since in absolute majority of cases libc is the first library searched
> > for symbols, all pthread references will be bound to it and failure
> > described by Doug will not happen.
> >
> > Any library providing strong pthread_ definitions will be able to
> > override ones provided by the system.
> 
> Something along these lines appears to work nicely and ought to work
> either with or without libXThrStub, which is now redundant since libc will
> be providing strong symbols that override all the weak symbols in
> libXThrStub. We should adjust the XFree86-4-libraries port to avoid
> building and using that library.

Please no, you've got strong pthread_* symbols in libc.  I'd rather
see them as strong in libpthread (but don't really want that either).

You can also play the libgcc game inside of libc for those applications
or libraries that are too lazy to do it for themselves.  Have the
libc pthread stubs key on a weak reference to pthread_create and
call the pthread_* if they are present.  libXThrStub should be
able to do that though.

-- 
Dan Eischen


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?Pine.GSO.4.10.10210310926070.27891-100000>