sparc64 built from jh branch

Ivan Kabaivanov chepati at yahoo.com
Fri Oct 12 11:43:30 PDT 2007


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



More information about the lfs-dev mailing list