condensed version of question about toolchain build

[Robert P. J. Day]

On Fri, 9 Sep 2005, Yann E. MORIN wrote:

> Robert,
>
> Quoting "Robert P. J. Day" <rpjday@mindspring.com>:
> > On Thu, 8 Sep 2005, Dan Kegel wrote:
> > > By "in one step", what do you mean exactly?
> > > Telling crosstool to use the non-sanitized headers, perhaps?
> > sorry, that was badly worded so let me turn this into a much simpler
> > question.  is there any drawback to building a toolchain using
> > sanitized headers as opposed to a full kernel source tree?  i ask
> > since it appears that it's the kernel configuration step that's
> > causing the problem, and that's obviously bypassed if you're just
> > using headers.
>
> If I'm not mislead, then you should _NOT_ build userland
> applications (be it toolchains or what ever) against 'vanilla'
> kernel headers, but using the sanitized headers.
>
> Google a bit, and I'm sure you'll find usefull and in-depth
> explanations about this.
>
> Roughly, 'vanilla' kernel headers contain internal object
> descriptions and functions, or even objects themselves, that shall
> not be available from userland, and that is the reason why the
> sanitized headers were made. In fact, they are extracted from the
> kernel tree and cleaned up, hence the term 'sanitized'.
>
> So IMHO your '2-pass' build is in fact the Good Way To Go (TM),
> whereas using the kernel headers is a Bad Thing (TM).

ok, all of this makes sense since, in my case, trying to use an actual
kernel source tree causes the build to fail for an obvious reason.

as i understand it, the only use for the kernel source tree is to
configure it for the target architecture, then grab the appropriate
headers (the step that the sanitized headers makes redundant.)  part
of that kernel source configuration step is to run (for the SH
architecture):

  $ make ARCH=sh oldconfig

i can see in the output the configuration being done, immediately
followed by a command to compile something under the "scripts/"
directory.  but that compile fails, complaining about invalid "-mb"
and "-m3" options, which are clearly SH-specific options. the native
compiler doesn't understand those options, and therefore fails.

it *appears* that those (at this stage, inappropriate) options are
being forced on the native compile by the arch/sh/Makefile, so trying
to build for SH using a kernel source tree seems guaranteed to fail,
unless i'm reading something hideously incorrectly.

thoughts?  am i just not getting something here?

rday

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com