Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 31 Oct 2002 09:07:35 +0000 (GMT)
From:      Doug Rabson <dfr@nlsystems.com>
To:        ak03@gte.com
Cc:        Daniel Eischen <eischen@pcnet1.pcnet.com>, <tlambert2@mindspring.com>, <current@FreeBSD.ORG>
Subject:   Re: [PATCH: libc]Re: gnome on current
Message-ID:  <20021031090443.T22480-100000@herring.nlsystems.com>
In-Reply-To: <20021031000501.3e20a6a6.kabaev@bellatlantic.net>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

Our libc is quite different. We define a (weak) set of _pthread_* symbols
and libc_r defines a set of strong _pthread_* symbols and a set of weak
pthread_* aliases for them.

It sounds like libc should define weak _pthread_*, and weak pthread_*
aliases for them. Libc_r should define strong _pthread_* symbols and
libc's aliases will then resolve to them. That ought to work quite well in
this situation and should satisfy everyone.

-- 
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?20021031090443.T22480-100000>