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

Re: etch-m68k and newer packages

On Sun, 29 Nov 2009, Stephen R. Marenka wrote:

> On Sat, November 28, 2009 7:12 pm, fthain@telegraphics.com.au wrote:
> > There are some packages that I'd like to see built under etch-m68k. 
> > From the gcc-4.2 build failures that Stephen showed us, I have my 
> > doubts about packages in the testing/unstable suites.
> >
> > I'd like to see some etch-m68k buildds put to work on the NPTL tool 
> > chain. I was able to cross-compile the debian sources plus TLS/NPTL 
> > patches.
> >
> > There's still a couple of issues. Firstly the ABI is not finalized. 
> > But that doesn't mean that the exercise is not useful. In particular, 
> > binutils-2.19.51 can be uploaded. The new kernel and kernel headers 
> > would then be needed, but cannot be uploaded.
> So binutils-2.19.51 should be built with which compiler? Any patches 
> needed?

No patches were needed when I cross-compiled the debian sources since the 
m68k TLS code is already in the snapshot. I used a variety of compilers, 
etch gcc should be fine.

> > Another issue is one of the requirements of eglibc-2.10, which is gcc 
> > >= 4.2. One way around that is to patch out that version check for 
> > building the glibc headers. Given the headers, it is possible to build 
> > gcc-4.4.
> So we need to build eglibc with gcc 4.2 or 4.4? Any patches against 
> debian sid?

Yes, eglibc-2.10 needs to be compiled with gcc-4.4 because TLS support has 
only been backported to gcc-4.4.

But gcc-4.4+TLS needs to be built against eglibc-2.10+NPTL, so there's a 
circular dependency here.

You begin to break that circular dependency by first installing the 
eglibc+NPTL headers using the etch compiler, gcc-4.1.1 (this requires a 
patch to eglibc to circumvent the gcc version check).

Getting the eglibc+NPTL headers also requires kernel headers from 
linux-2.6.31+TLS. This is partly why we need to wait for the ABI to 
stabilise. Hence, at this point, only binutils can be uploaded.

Binutils+TLS and kernel+TLS (binary and headers packages) are the first 
packages needed, and they can all be built from stock etch-m68k (debian 
build deps permitting, that is. The upstream packages themselves don't 

> > The third issue that comes to mind is gcc itself. It seems to me that 
> > all gcc packages should drop the finline-gnu89 patch that only m68k 
> > uses. I think it is there solely for glibc-2.5 (and I don't trust that 
> > binary anyway).
> Should this be after we get eglibc-2.10 functional? All we have right 
> now is glibc-2.5, right?

The gcc-4.2 build failure we looked at was apparently due to glibc-2.5.

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.

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.


> Thanks,
> Stephen

Reply to: