Fedora and Cross Compiling

[Ralf Corsepius]

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.

> 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.

> 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.

> I favor a combination of #2 and #3.
FWI: What I am doing for my cross-toolchain rpms is to generate the
specs from a other, shared spec templates/fragments. 

>   I'll see about adapting your 
> binutils patch to accommodate multiple targets, unless people think this 
> is a really bad idea.
This idea probably can be made functional for targets addressing
different archs of the same OS, but it doesn't work across OSes nor for
embedded targets, because vendors often have different patches applied,
even to binutils.

Also, there occasionally are problems stemming from certain host/target
combinations which render one of binutils/gcc/gdb components unbuildable
for one host/target pair. A combined binutils is not unlikely to suffer
from the same issues, which would mean "one broken" host/target pair is
likely to block out all (E.g. I recently found binutils-2.17 for target
sparc-rtems* to bomb out on x86_64, which they build flawlessly on
i386).

Ralf