Fedora and Cross Compiling

[David Woodhouse]

On Wed, 2007-06-13 at 08:48 +0200, Ralf Corsepius wrote:
> On Wed, 2007-06-13 at 00:25 -0600, Brendan Conoboy wrote:
> > David Woodhouse wrote:
> > > Do we _actually_ need to build parts of glibc? Could we not get away
> > > with a fake DSO which just provides the few symbols libgcc uses?
> > 
> > [snip]
> > 
> > Will follow up on this part tomorrow.  I disfavor faking it, as it were.
> > 
> > > Binutils at least should be relatively easy. Here's a patch against
> > > binutils/F-7 which lets me:
> > >   make DIST_DEFINES='--define "binutils_target i686-linux-gnu"' ppc
> > > 
> > > Even for this we have build system questions... how best to build it for
> > > each target architecture we want?
> > 
> > Generally, I think Hans and the rest at 
> > http://fedoraproject.org/wiki/SIGs/Embedded have the right idea here. 
> > Prefixing the target name to the package is a good plan for most 
> > crosses.  More fully, I see 3 options:
> > 
> > 1.  One srpm to rule them all.  This seems like a bad idea as it doesn't 
> > scale.
> Right, it doesn't. You'd end up with a monsterous spec cluttered with
> cases and many (unused) patches, because different vendors apply
> different patch sets.

The same was true of the kernel until we started slapping people and
making them push their code upstream rather than dumping it in the RPM,
and banning the use of %ifarch in the specfile (at least for applying
patches).

Having applied that discipline, this approach _does_ seem to work for
the kernel. (So far, at least).

I think Jakub does a good job of keeping patches to a minimum for the
toolchain, just as we do for the kernel. Why should we expect less from
those involved in cross-compilers?

When I build an i386-fedora-linux-gnu cross-compiler package, I want
that to be exactly the same compiler as the 'native' i386 compiler. 
The approach I've taken with binutils allows that.

Perhaps we wouldn't get away with the same for gcc, but it would be nice
if we could.

> > 2.  One srpm which generates multiple crosses.  This might be in the 
> > form of one package for the Fedora mesh, another for all mips targets, 
> > and so forth.  The realm of when somebody wants to be a cross-arch-czar 
> > or there is some technical reason to bunch them together.
> I am having doubts this can work, either, because different
> architectures/target OS aren't necessarily in a shape to be using the
> same sources. 
> 
> It definitely don't apply to embedded targets, which tend to require
> different versions on different architectures.

We really don't want to pander to this. If an architecture cannot work
with a current toolchain, then we should just ignore it until the
toolchain is fixed. They can get it working upstream, or they can sod
off.

Otherwise, they'll be asking us to ship their vendor-hacked 2.6.9 kernel
next... and then we'll have to hurt them.

> > 3.  One srpm which generates packages for a single cross, like Hans's 
> > arm-gp2x-linux-package effort
> IMO, this is the only viable approach. It bloats the repos and requires
> some effort to assure packaging consistency when targeting several
> architectures/OSes, but it's basically what I am doing.

This would be a little nicer once we move to git and can just pull
changes from Jakub's 'master' Fedora toolchain packages.

-- 
dwmw2