Re: gcc 4.5 and TLS
fthain@telegraphics.com.au dixit:
>One possible solution for a native build is, in sequence,
>
>1. binutils
>2. gcc
>3. libc
>4. gcc
>5. libc
>
>...installing each package as it is built, before building the next one.
That was approximately how I planned it. (Why is it that gcc needs,
at build time, the headers of the target system for GNU libc based
systems? It doesn’t need them for, for example, a cross-compiler
targetting MirBSD.)
>(I haven't tried this. Perhaps the TLS devs can chime in?)
-v -h please.
>Anyway, since these are native builds, steps 3+ need to happen running
>under a kernel with TLS support (which could be built with a plain
>etch-m68k tool chain last time I tried it). You also need the kernel
>headers from this kernel to be installed prior to step 3.
Okay. Are mine? I have:
• vmlinuz-2.6.26-1-atari (linux-image-2.6.26-1-atari 2.6.26-13)
• vmlinuz-2.6.29-2-atari (linux-image-2.6.29-2-atari 2.6.29-5)
>The best advice I've been given is to use a TLS/NPTL enabled cross
>tool-chain to build the complete libc, and simply install that (with
>kernel headers) in your chroot before building the native gcc.
Hm. If it’s possible to build a TLS/NPTL enabled cross compiler,
it must somehow be possible to build (forcibly) one for native
builds as well, I think.
>To be sure, you'd then rebuild the whole of the buildd userland. And
>finally rebuild the whole tool-chain again in a clean new buildd made up
>of this new userland.
Yeah, that’s obvious. I’d like to do that anyway, as I’m building
in a regular system at the moment, once I have a cowbuilder.
bye,
//mirabilos
--
FWIW, I'm quite impressed with mksh interactively. I thought it was much
*much* more bare bones. But it turns out it beats the living hell out of
ksh93 in that respect. I'd even consider it for my daily use if I hadn't
wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh
Reply to: