Re: gcc 4.5 and TLS
On Tue, 20 Apr 2010, Thorsten Glaser wrote:
> fthain@telegraphics.com.au dixit:
>
> >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)
TLS/NPTL support will not be released until 2.6.34. But backporting the
patches to sid's 2.6.32 should be trivial (I used 2.6.31).
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=9674cdc74d63f346870943ef966a034f8c71ee57
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=5da3a65d2d1ba333d61999640ef241f150c69c6b
>
> >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.
The Linux From Scratch books describe a process like that.
It isn't so much a question of "forcing" as divorcing the compiler from
the host system and it's libraries.
That is, the aim is to build a tool chain that targets a slightly
different setup. And that is the essence of cross compiling, even when
only one architecture is involved. So cross-compiling ends up being an
efficient solution.
Finn
Reply to: