Re: Kernel Cross Compiling [update]

From: Herbert Poetzl
Date: Tue Feb 24 2004 - 03:54:57 EST


On Mon, Feb 23, 2004 at 05:49:29PM -0800, Dan Kegel wrote:
> Herbert Poetzl wrote:
> >my primary goal isn't to get this fixed by the gcc folks,
> >I want to have a simple and working solution, which seems
> >to be at hand for the toolchains, to cross compile the
> >linux kernel for testing purposes. the changes so far are
> >not very intrusive IMHO, and I can live with a few patches.
> >(btw. currently Dan Kegel has a lot more patches to gcc in
> >his toolchain than I do)
>
> My crosstool package has very, very few patches, and each
> patch is carefully documented.

damn! It the last thing I wanted to do ...

my dearest apologies, Dan, it was not and is not my intention
to make your work bad in any way, on the contrary, I really
appreciate what you are doing, and I'm glad that something
like crosstool exits ...

best,
Herbert

> (You can see them at http://kegel.com/crosstool/current/patches/gcc-3.3.2/ )
> The patches that end in -test.patch simply add testcases to the gcc
> regression test. Several of the other patches simply fix testsuite
> problems.
> The only patches that actually affect gcc are
>
> http://kegel.com/crosstool/current/patches/gcc-3.3.2/gcc-3.3.2-arm-softfloat.patch
> http://kegel.com/crosstool/current/patches/gcc-3.3.2/sh-lib1funcs_sizeAndType.patch
> http://kegel.com/crosstool/current/patches/gcc-3.3.2/sh-libgcc-hidden.patch
> http://kegel.com/crosstool/current/patches/gcc-3.3.2/sh-pic-set_fpscr-gcc-3.3.2.patch
>
> I only add a patch after I have verified that it fixes a problem,
> and I document what that problem is at the top of the patch;
> when possible, the patch starts with a link to gcc's bugzilla for
> the problem it fixes.
> Fairly often, my patches are simply backports from cvs.
>
> Debian, by comparison, builds gcc with huge collections of
> patches that are not
> documented at all. Likewise, Red Hat uses quite a few patches.
> I don't want to say the Debian and Red Hat compilers are bad,
> but I *do* want to say that crosstool builds compilers that are
> extremely close to vanilla, with all departures from vanilla
> carefully documented.
>
> By the way, I agree with Jim Wilson's remark:
> > As a gcc
> > maintainer, it makes my job harder when people are building the compiler
> > different ways, because I may get bug reports that I can't reproduce or
> > understand. Also, there is a risk that a kernel-only cross compiler
> > will accidentally be used for some other purpose, resulting in a bug
> > report that wastes the time of the gcc maintainers.
>
> That's why I suspect crosstool is a good toolchain for anyone who
> wants to report bugs to the gcc folks; it's tightly controlled,
> very close to vanilla, and has support for (gasp) running the gcc
> and glibc testsuites in a cross-development environment.
>
> - Dan
>
> --
> US citizens: if you're considering voting for Bush, look at these first:
> http://www.misleader.org/
> http://www.cbc.ca/news/background/arar/
> http://www.house.gov/reform/min/politicsandscience/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/