From: Dan Kegel <dank@kegel.com>
To: Herbert Poetzl <herbert@13thfloor.at>
Cc: Jim Wilson <wilson@specifixinc.com>,
linux-kernel@vger.kernel.org, Judith Lebzelter <judith@osdl.org>,
cliff white <cliffw@osdl.org>,
"Timothy D. Witham" <wookie@osdl.org>
Subject: Re: Kernel Cross Compiling [update]
Date: Mon, 23 Feb 2004 17:49:29 -0800 [thread overview]
Message-ID: <403AADA9.3040803@kegel.com> (raw)
In-Reply-To: <20040223203257.GA9800@MAIL.13thfloor.at>
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/
next prev parent reply other threads:[~2004-02-24 1:54 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-22 3:53 Kernel Cross Compiling [update] Herbert Poetzl
2004-02-22 6:02 ` Dan Kegel
2004-02-22 15:42 ` Herbert Poetzl
2004-02-22 8:43 ` Geert Uytterhoeven
2004-02-22 9:07 ` Russell King
2004-02-22 15:09 ` Herbert Poetzl
2004-02-22 12:45 ` Dr. David Alan Gilbert
2004-02-22 15:22 ` Herbert Poetzl
2004-02-22 15:52 ` Paul Mundt
2004-02-22 17:07 ` Herbert Poetzl
2004-02-22 17:23 ` Paul Mundt
2004-02-23 13:28 ` Richard Curnow
2004-02-23 14:41 ` Herbert Poetzl
2004-02-26 13:02 ` Richard Curnow
2004-02-23 19:42 ` Jim Wilson
2004-02-23 20:32 ` Herbert Poetzl
2004-02-24 1:49 ` Dan Kegel [this message]
2004-02-24 8:53 ` Herbert Poetzl
-- strict thread matches above, loose matches on Subject: below --
2004-02-22 16:36 Arnd Bergmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=403AADA9.3040803@kegel.com \
--to=dank@kegel.com \
--cc=cliffw@osdl.org \
--cc=herbert@13thfloor.at \
--cc=judith@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=wilson@specifixinc.com \
--cc=wookie@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox