Re: crosstool build matrix ambiguity

[Allan Clark <allanc at chickenandporn dot com>]

Robert P. J. Day wrote:

> On Sun, 24 Apr 2005, Allan Clark wrote:
>
> ... snip ...
>
>  
>
> > Is there a difference whether I build a toolchain with linux headers
> > from 2.4.19 versus one with headers from 2.6.12?
> >
> > I ask this question to make a point: should the TOOLCHAIN variable
> > be expanded to include kernel version as well?
> > gcc-3.4.3-glibc-2.2.5-linux-2.4.19 ?
> >    
>
> (actually, i think it's the TOOLCOMBO variable you're thinking of.)
>  
<blush> err... ah... yeah.

> this is something i've wondered about for a while.  if you really
> wanted to be pedantic, the TOOLCOMBO variable would technically
> include *all* of the versions of gcc, glibc, binutils, the linux
> kernel, whether sanitized headers were used, and maybe even the
> version of the host compiler.
>
> obviously, that's absurd but it sure seems to be tending in that
> direction.  what about just overriding that whole combo with some
> meaningful (to the builder) keyword.  for instance, if i'm building an
> ARM toolchain for my zaurus, i'd just as soon replace that whole
> string with "zaurus" since i would know what that meant, and i really
> don't care if anyone else understands the underlying combination.
>
> thoughts?
>  
How much different should the resulting toolchain be for different host 
compilers?  As well, I would assume that some crosses can only be built 
with either sanitized or unsatitized, and a range of binutils.  There 
should not be a huge difference in the resulting toolchain for those 
variables as there is for 2.4.x vs 2.6.x kernels, but then I assume this 
same logic was used to *not* define the kernel version previously.

I would agree that "pxa271-2.4.19" would probably be the toolchain I am 
building.  It makes sense to give a logical name.

The discrepancy I am pointing at is the RPM/SRPM work... I'm trying to 
differentiate a (gcc/glibc/linux) 3.2.3/2.2.5/2.4.19 toolchain from a 
3.2.3/2.3.3/2.4.19 toolchain from a 3.2.3/2.2.5/2.4.21 toolchain in RPM 
depenedencies, and would want them all to possibly coexist.  I've lost 
my current contract (ie sponsorship for my hacking), but working to pick 
up another where I would be standardizing the build process for a 
company's linux-based consumer devices, and I've Drank the Koolaid on 
RPM dependencies and "apt-get upgrade".  This co-existing and RPM 
subpackages granularity would help verify the kernel versions too.  I 
currently am too lazy to show sanitized/un-, binutils versions, etc.

Maybe we want to be able to configure how the TOOLCOMBO variable is built ;)

Allan
--
Embedded Linux consumer products: forcing a Rhino into a shoebox


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