Re: etch-m68k and newer packages
On Mon, 30 Nov 2009, Stephen R. Marenka wrote:
>
> On Sun, November 29, 2009 6:59 pm, fthain@telegraphics.com.au 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
Reply to: