Cross-compilers.

[Ralf Corsepius]

On Sun, 2006-09-17 at 22:41 -0400, Brendan Conoboy wrote:
> David Woodhouse wrote:
> > Starting with binutils.... at http://david.woodhou.se/binutils.spec
> > there's a specfile based on the current Core package which lets you
> > build cross-binutils with for example 
> > 	--define "binutils_target i686-fedora-linux"
> 
> Any particular reason for the binutils in binutils_target?  Something 
> like target_triplet could be shared across multiple packages (gcc, gdb).
s/could/must/ wrt. GCC

>   Also, putting some form of Fedora in the name is great, but it should 
> be in some way versioned like i686-fedora5-linux or even i686-fc5-linux. 
>   This is a little more specific and will scale better if cross compiler 
> interest blossoms.
Using a versioned target-triple is inevitable for cross-toolchains,
because the toolchains aren't necessarily compatible.

> > That approach lets us track the Core package directly, and I think is
> > sanest. What I'm not sure of, however, is how we actually deal with that
> > when building for Extras. Is there a simple way we can build it multiple
> > times with multiple definitions of %binutils_target, or would we have to
> > import it all into multiple directories in CVS with the requisite
> > one-line change and then build each one normally?
> > 
> > Another possibility is that we could make a single SRPM spit out _all_
> > the $ARCH-fedora-linux-binutils binary packages, building them all in a
> > loop. But that might involve diverging even more from the Core specfile,
> > which wouldn't be ideal.
> 
> This seems like a pretty small divergence.  Instead of target_triplet 
> use target_triplets, use a for loop and you're scarcely any further from 
> the original spec file.  That said, three downsides come to mind:
> 
> 1.  The build will become increasingly slow as targets are added.
> 2.  A build failure of one target may prevent any target RPMs from being 
> produced (optional).
This might not be much of an issue for RH-based toolchains, but in
general, but in general, in practice, this is a real showstopper to such
multiple target cross-toolchains and it renders this approach to be
impractical. Experience tells, one target is always broken somewhere and
not all GCC versions work for all targets.

Furthermore, fixing target specific bugs introduces unnecessary rebuilds
for other targets - This renders this approach to be a pain to
end-users.

> 3.  If people want to take the idea and run with it for other targets, a 
> single SRPM means less flexible maintainership.
> 
> The question that's been gnawing on my mind since your original posting 
> is: Where does the sys-root come from?
The easiest approach is to repackage the original (native) Fedora rpms
into noarch rpms containing the sys-root for a cross toolchain.

Ralf