On Mon, 30 Nov 2009, Stephen R. Marenka wrote:
> > On Sun, November 29, 2009 6:59 pm, [email protected] wrote: > > > That's why I'm interested in etch-m68k (glibc-2.3.6) buildds. I don't > > see any role for glibc-2.5 in the process of updating to a tool chain > > based on eglibc-2.10, binutils-2.19.51, gcc-4.4.1, linux-2.6.31. So I > > don't see any need for the finline-gnu89 patch at all. Moreover, I > > worry that it may actually cause problems. I meant, "fgnu89-inline". BTW, I found that it is possible to patch glibc-2.5 instead of gcc to get (what appears to be) the same effect. > > > > My only reservation is that the various eglibc/binutils/gcc/linux > > packages have numerous build deps that may not be satisfied by the > > packages in etch-m68k. That's the main sticking point I can see, but > > we may be able to address this before the ABI stabilises. > > The other problem with etch-m68k is that we can't make changes to that > distribution any more. It sounds like we should bootstrap sid's > toolchain (and friends) starting with etch-m68k. I think it is worth a try. At least up to the point where we can run the eglibc and gcc testsuites. (I'm still trying to find time for that exercise). > > Are we going to end up recompiling the archive for TLS any way? Hard to say. There are certain packages that need NPTL and others that can be built with NPTL support when available. Some of the ABI changes are in fact bug fixes. If I understand correctly, the signal handling is broken. So packages statically linked against the existing libc ought to be rebuilt. Perhaps also some other packages like busybox that don't link against glibc at all. I suspect that there are new features in the glibc 2.5 -> 2.10 upgrade which could justify rebuilding some binaries... but I don't know for sure. Finn -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
