[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.

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: