lkml.org 
[lkml]   [2004]   [Feb]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Kernel Cross Compiling [update]
    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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:01    [W:0.025 / U:128.292 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site