Date: Fri, 22 Apr 2005 15:48:45 -0400 (EDT) From: Daniel Eischen <deischen@freebsd.org> To: Scott Long <scottl@samsco.org> Cc: freebsd-arch@freebsd.org Subject: Re: libpthread version bump Message-ID: <Pine.GSO.4.43.0504221539580.24214-100000@sea.ntplx.net> In-Reply-To: <42694DAC.5090505@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 22 Apr 2005, Scott Long wrote:
> Warner Losh wrote:
> >>Having lived through the std{io,err,out} libc snafu, the
> >>libm.so.2 snafu, and now the libc.so.5/libpthread.so.1
> >>problem, I will once again suggest that *ALL* library
> >>version numbers should be bumped when a new branch is
> >>created.
> >
> >
> > Yes. When a library version is bumped, *ALL* libraries that depend on
> > it need to be bumped. Sadly, this has proven to be too difficult
> > because it would create an unholy maintanence problem for the ports.
> >
> > Warner
>
> Well, there is indeed a problem at the moment of libc being bumped for
> 6-current but not libpthread. However, I think that the particular
> problem with the fs/gs change goes above and beyond this problem. So,
> we have about 2 months to sort this all out. Any volunteers?
I'm not sure I fully understand the problem, but can't you
just make libpthread avoid using *setbase() if the symbol
isn't available and use the ldt functions as a fallback?
#pragma weak i386_get_gsbase
static void *have_gsbase = i386_get_gsbase;
...
if (have_gsbase == NULL) {
/* use ldt stuff */
}
else {
/* use i386_get_gsbase */
}
You just need something else to force the symbol i386_get_gsbase
to be loaded; the #pragma weak won't force it to be loaded even
if it is present.
--
DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.43.0504221539580.24214-100000>