On Tue, 20 Apr 2010, Thorsten Glaser wrote: > fth...@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 -- To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.lnx.2.00.1004210928410.12...@nippy.intranet
