Re: Kernel Cross Compiling [update]

[Dan Kegel]

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.
(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/