On Thursday 11 October 2007 20:39, Jeremy Huntwork wrote: > Hello, > > Well today I finished a sparc64 build based on the jh branch. Has anyone > else done a native build on sparc hardware adapted from recent LFS? >
Jeremy, thanks so much for bringing this up. I've been compiling successfully LFS since at least 5.0 on ppc and sparc64 and have always wanted to see these two be semi-supported by LFS proper. Just a few comments. I prefer to build a 32bit userland and 64bit kernel. This has been the advice of the ultrasparc gurus for a long time and as recently as a few months ago there was a discussion either on debian-sparc or gentoo-sparc that reiterated this original point. I didn't have to modify the LFS instructions *at all* except to add two or three extra packages needed by sparcs. However, I had to compile a cross compiler for the 64bit kernel, which would be a major difference from stock LFS book. As I wrote in a previous thread on this list, with all due respect and appreciation to the CLFS devs, I simply can't see a need for this project other than as a collection of useful tips that can be applied to LFS. You can build stage5 on a x86 for sparc64 target, but you can't chroot into that. So then what's the point? Directing people who express interest in other architectures to CLFS is fine, but it doesn't help them build a full LFS unless they're building on x86_64 for x86 or some other combination of architectures within the same arch family (ppc->ppc64, sparc->sparc64). And while I agree that some devs' reluctance to include ppc, sparc, etc to the stock book is due to the lack of support, and the lack of developers actively hacking on these architectures, I wonder if this is an egg-and-chicken question. There are not enough ppc/sparc/etc devs because LFS does not officially support ppc/sparc/etc? I think what Dan suggested and what Jeremy in essence is doing is to start an experimental support in a separate branch (I thought jh_branch had this goal; well that and multilib if I'm not mistaken, which is same thing actually) and see how it matures. And one more thing -- ipcop, based on LFS, will support ppc and sparc in its next version. We already have working ppc and sparc support in svn (well sparc is slightly unbootable, but that's a kernel problem that I'll be addressing soon, I hope). SVN is based on LFS-dev from april, but it's on my TODO list to bring it up to LFS-6.3 in the next few weeks when I find some more time. So, adding support for ppc and sparc64 to LFS is not so difficult and without a precedent. ppc boot support for OldWorld macs is quite problematic though and it involves some voodoo magic. If you do decide to offer some kind of support for ppc I would advise initially only supporting NewWorld ppc machines (anything since the original iMac). And on the topic of bootloaders, GRUB2 has experimental support for ppc and there are plans to support sparc as well. So at some point in the hopefully near future even that difference will disappear. And here are the two extra sparc64 packages: sparc-utils (ftp://ftp.debian.org/debian/pool/main/s/sparc-utils): provides elf2out, sparc32, prtconf and eeprom silo: the sparc bootloader Oh, and one last thing, in order to build a 32bit userland on an ultrasparc every command in the book that has a bash needs to be sparc32 bash -- this fools the shell into thinking we're running on a 32bit sparc. Which means sparc-utils must be the very first statically built package in stage5. This saves you the trouble of cross compiling. IvanK. > I'm hesitating adding in the necessary changes to the branch. When it > comes down to it, the changes aren't that bad, but I just wanted to > sound it off someone else first. > > * GCC need some compiler flags set for sparc64 - some packages will > fail otherwise. -mcpu=ultrasparc -mtune=ultrasparc works for my > processor. So, for chapter 5 and 6, set an environment variable of > CC="gcc f-mcpu=ultrasparc -mtune=ultrasparc". Most packages pick that up > from the environment with the configure stage. Some few need it passed > to make, like 'make CC="$CC"' Programs that require adding a 'CC=' to > the make command are (IIRC, my notes are at work): > procps > bzip2 > sysklogd > sysvinit > util-linux > udev > > * util-linux needs a patch in chapter 5 & 6, CLFS calls it a syscall > patch. Trying to work it into a sed, but the changes CLFS made are a > little extensive. > CLFS also created a patch to add a missing header for swapon.c, > needed in chapter 6: util-linux-2.12r-missing_header-1.patch. But this > patch could be traded for a sed: > sed -i '/stat.h/a\#include <fcntl.h>' mount/swapon.c > > * kbd requires two seds for sparc architectures: > sed -i '/kbdrate/s/period/rate/' src/kbdrate.c > sed -i '/kbio.h/d' src/{kbdrate,setleds}.c > > > Anyway, that's it. All things considered, it's not that bad. Also, > that's it for the hardware I have (currently) available to test with: > x86, x86_64, sparc{,64}, and ppc. > > -- > JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
