On Tue, 20 Apr 2010, I wrote: > and you need [glibc with NPTL] before you can build gcc with TLS.
Well, this isn't quite right. I'm told that you can get __thread support from gcc 4.5 without having to have NPTL support in your libc. Problem is, that compiler will have fixed includes, libgcc, libstdc++ libraries etc all derived from and targeted at the system libc, which is not what you want, since this libc is from etch-m68k and lacks NPTL. > > This amounts to a circular dependency. When bootstrapping a cross > toolchain, the cycle is broken by building some libc object files early > and by building several compilers. Given a complete cross toolchain, > there are other solutions available. 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. (I haven't tried this. Perhaps the TLS devs can chime in?) 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. 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. 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. 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.1004201945000.4...@nippy.intranet
