On Sun, 29 Nov 2009, Stephen R. Marenka wrote:
> > On Sat, November 28, 2009 7:12 pm, fth...@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 > > -- To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
