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
care).
> > 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.
Finn
>
> Thanks,
>
> Stephen
>
>
Reply to: