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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
