Re: glibc-2.4 released (was: Re: never mind: no linuxthreads in glibc-2.4)

["Robert P. J. Day" <rpjday at mindspring dot com>]

On Mon, 13 Mar 2006, Dan Kegel wrote:

> On 3/13/06, Martin Guy <martinwguy@gmail.com> wrote:
> > For immediate testing with crosstool < 0.43 you can simply set
> >
> > GLIBC_DIR=glibc-2.4
> > GLIBC_THREADS_FILENAME=glibc-ports-2.4
> >
> > which both prevents it from automatically adding the threads file and
> > simultaneously perverts its linuxthreads code to apply the ports
> > collection instead. By a stroke of luck it already knows about cd-ing
> > into the glibc dir before unpacking anything called glibc-[a-z]*-2*
>
> Clever / lucky!
>
> > The real solution is a GLIBC_PORTS_FILENAME clause, since older
> > versions have both 2.3.6-linuxthreads and 2.3.6-ports, and to embed
> > knowledge only to set GLIBC_THREADS_FILENAME by default if glibc < 2.4.
> > Or maybe always to add the ports collection instead of the threads tarball
> > if glibc >= 2.4
> > What seem righter?
>
> How about:
> * making GLIBC_THREADS_FILENAME optional, and if it's missing,
>   we don't try to unpack it
> * requiring GLIBC_PORTS_FILENAME to be set if we want the ports
>   addon loaded
> In other words, avoiding embedding knowledge about this stuff in crosstool.
> It's tempting to look at regularizing how glibc addons are handled in crosstool,
> since as you discovered, glibc addons do seem to follow a logical
> pattern of sorts.
> - Dan

what are the chances of getting a high-level overview of the
consequences of dropping linuxthreads from glibc-2.4?  short-term
fixes?  long-term goals?  implications for crosstool?  that sort of
thing, just so some of us can still follow along.

rday

p.s.  i've never tried this but what's the value in trying to build a
toolchain with no thread support at all, just to temporarily get
around this if one just wants to test building with glibc-2.4?

--
For unsubscribe information see http://sourceware.org/lists.html#faq