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

["Dan Kegel" <dank at kegel dot com>]

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

--
Wine for Windows ISVs: http://kegel.com/wine/isv

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