glibc-2.2.5 patch for sparc

IvanK. chepati at
Thu Oct 3 16:56:34 PDT 2002

Well, it turns out supporting sparc in the official lfs book might not be a 
good idea after all (read probably too much trouble for too little of a 

I'm in discussion with David Miller on the sparclinux mailing list and 
basically he says that kernels for sparc64 are to be compiled with an old 
compiler, egcs64.  He went further to state that gcc-3.2 has known issues 
compiling sparc64 kernels.  I have been using 3.1 to compile 2.4 series and I 
believe it's ok to use that compiler, but I'll hear from Dave soon whether 
even 3.1 is good.

What all this boils down to is that if sparc64 (not too sure about plain old 
sparc) were to be officially supported in the book, we have to include egcs64 
in lfs-packages, and have an extra section on compiling egcs64.  At this 
point a portion of the audience will be too confused and may think egcs64 is 
required even for x86 platforms.

Therefore, until the big names in sparclinux write patches for gcc3.2 or until 
a new version (or cvs) of gcc safely compiles a sparc64 kernel, we shouldn't 
be describing sparc lfs building in the book and we should have a hint 
instead.  Like I said before, chapter2/platforms would be a good place to put 
a link to a hint.  But until I (or someone else) write(s) this hint, such a 
link cannot be inserted.

Mind you, gcc-3.2 is good for compiling userland on sparc, though.

Lastly, as time permits, I'll document a lfs build on a sparc and submit it to 
you guys for consideration whether to integrate into the book or have as a 

Sorry for the long post, but I hope it'll prevent an even longer thread.


On Thursday 03 October 2002 07:29 pm, Seth W. Klein wrote:
> Matthias Benkmann <matthias at> wrote:
> > On 03 Oct 2002 20:18:47 +1200 Zach Bagnall <yem at> wrote:
> > > If the change does not effect other architectures, I suggest it be
> > > added into the book
> >
> > That means more patch-reading for non-SPARC users (who are the majority).
> > Not everyone applies patches blindly. And if we start incorporating SPARC
> > patches, we'll have to add PPC,... too and in the end we'll have tons of
> > patches that the majority doesn't need to read. Patches are a last
> > resort. There should be as few as possible in the book. I really think
> > that this should better be in a SPARC hint. Note that there is no minimum
> > size for hints. A hint that just contains "Apply this patch to glibc and
> > everything else will work by the book: <patch>" is fine.
> One of the advantages to open (free) source in general and building
> from scratch particular is that it is not tied to an architecture.
> This is useful because there are various reasons to use architectures
> besides x86. Battery life on PPC notebooks is one i know.
> Truely supporting other architectures in the book requires little.
> For PPC, i know of need for a bootloader page and one compile option
> which is already in the book. Power management daemons and such are
> likely BLFS material.
> If you (Matthias) object to lengthening a generic patch, the patch
> (which is trivial, IIRC) could probably be separate and marked for
> SPARC only just as there have been separate instructions for some
> AMD machines.
> cheers,
> Seth W. Klein

Unsubscribe: send email to listar at
and put 'unsubscribe lfs-dev' in the subject header of the message

More information about the lfs-dev mailing list