Fedora and Cross Compiling

[Ralf Corsepius]

On Thu, 2007-06-14 at 11:53 -0600, Brendan Conoboy wrote:
> Ralf Corsepius wrote:
> > Not quite. You end up with the target's sys-root's files ("target
> > binaries", blobs of arbitrary binary data) inside of a "noarch" rpm.
> 
> Er, if you're building an arm-linux toolchain and store the sysroot in a 
> noarch rpm, that's still wrong arch :-)
Why? To the host, a target's binaries are non-executable,
host-independent blobs of binary data (==arch).

>   Not *as* wrong as having it in 
> an RPM for the build host's arch, but not as right as having it for the 
> target arch.
That's right. 

But consider: a cross-toolchain is an ordinary (host) native
application, accessing target-files as ordinary data files when its is
executed.

I.e. a <target>-gcc running on <host> accessing the target's libc
basically does the same as a GUI application loading a *.png.

> > Well, IMO this plan is not useful and doesn't fit into the working
> > principles of rpm, because it confuses host architecture with target
> > architecture.
> 
> Eh?
Let me try to elaborate: 
You want to mix different archs inside of the host's rpmdb.

This doesn't harmonize with current rpm/rpmdb's concepts, because
rpm/rpmdb doesn't have a concept of "targets".

All it has is "host-independent" (==noarch) and
"host-dependent" (==<arch>) 

> > What I could envision to be made functional is a wrapper around rpm,
> > using another "per-cross-target" rpmdb to add native target rpms into
> > sys-roots.
> 
> If I understand you correctly, that sounds about right.
I noticed some mails outlining similar thoughts had crossed when writing
the sentence above :)


What I had in mind was to "installing foreign rpms" onto a secondary
"target rpmdb" and to reuse them for cross-compilers:

Very oversimplified, this would mean to install target-rpms into a
separate rpm-based "root" with it's own rpmdb, similar to this:

/usr/bin/<target>-gcc
/var/lib/rpm/ <--- "host rpmdb"
...
/usr/share/<target>/sys-root/var/lib/rpm <--- "target rpmdb".

In this example, target files administered inside of the "target rpmdb"
would be used for applications administered inside of the "host rpmdb".

rpm-wise the working principle probably would be very similar to that of
how mock and mach setup their chroots.


>   When cross 
> building you need to pull in a mixture of native (host-arch) and cross 
> (target arch) packages to meet the build dependencies.  This is part of 
> where the "fun" is.
Well, I question the "need", but consider this kind of implementation to
be "an option".

Ralf