[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 

> 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.


Reply to: