can build toolchain in two steps, but not one

Robert P. J. Day
Sun Sep 11 19:28:00 GMT 2005

On Sat, 10 Sep 2005, Dan Kegel wrote:

> Robert P. J. Day wrote:
> > On Sat, 10 Sep 2005, Dan Kegel wrote:
> >
> >
> > > Robert P. J. Day wrote:
> > >
> > > > credit where credit is due, it was a private e-mail from michael
> > > > that pointed me at the appropriate architecture makefile as the
> > > > source for some unwanted compiler options when trying to run the
> > > > *native* compiler.
> > >
> > > How about posting a patch to fix the kernel sources, now that you've
> > > found the problem?
> >
> >
> > but, again, is this really the direction you want to take?
> Think about it... are toolchains the only thing I build?

having just spent 13 hours driving across 5 states, i'm in the mood to
play devil's advocate.  from the perspective of crosstool, i don't
think it matters in the *slightest* what else you want to build.  let
me explain.

the primary and overriding purpose of crosstool is to build a
cross-compile toolchain, and that's it, nothing more.  the goal should
be to create the most reliable tool there is.  if (and i stress *if*)
crosstool were to do anything *extra* as a bonus, that's fine as long
as that bonus doesn't interfere in any way with crosstool's primary

now, i think we all agree that, when it comes to reliability, using
sanitized headers beats using a kernel source tree every which way to
sunday in terms of reliability.  so if we're talking about just
building a toolchain *and nothing more*, using the sanitized headers
is a no-brainer over the kernel source.  that's not even a point of
debate anymore.

your position seems to be that you also might like to cross-compile
the kernel as well, as a kind of freebie bonus.  i would contend
that's fine as long as this didn't affect the reliability of building
the toolchain.  clearly, though, that's not the case.  trying to use
the kernel source tree can obviously have an effect on building the
toolchain itself.

i contend this is a *very* bad thing.  the fact that a failure in the
kernel configuration can cause the build of the toolchain to fail is,
in my opinion, unacceptable.  those two are entirely independent
operations and linking them in this way is adding what is essentially
a totally bogus dependency to the toolchain creation.  let me suggest
an alternative.

if you're dead set on being able to compile the kernel source while
building a toolchain, make those two entirely independent operations.
let the toolchain build rely solely on the sanitized headers -- this
makes the toolchain build as simple and reliable as possible.

*then*, if the toolchain builds, the build script can test both of the
variables LINUX_DIR and KERNELCONFIG and, if they're both set to
meaningful values, the second step can be to cross-compile the kernel.
this would appear to solve all of the problems, no?  (that is,
LINUX_DIR is not used in any way in the toolchain creation --
sanitized headers are required.)

and, yes, i'm tired.  and, yes, adding kernel patches to get around
this is a bad idea.


Want more information?  See the CrossGCC FAQ,
Want to unsubscribe? Send a note to

More information about the crossgcc mailing list