Ralf Corsepius wrote:
> 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.
Yep clearly a cross compiler that runs on an i386 host and emits ARM or
any other target code is an i386 app destined for installation on i386
boxes, it would be something like gcc-arm5-linux-4.2-123.i386.rpm.
>>> 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 :)
Agreement is usually a good sign :-)
>> 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".
It can be necessary though, for example if the package build wants yacc
or bison or whatever to build, with cross building they are going to be
host yacc and bison despite you are building for a different target arch
-- it should go look in the host rpmdb to confirm they are available.
But if it wants libsomething-devel to build, because it knows it will be
compiling against it, it is talking about the target arch
libsomething-devel that it wants to see installed in the arch chroot
rpmdb. The only full answer I can think of is to improve rpmbuild and
the BuildRequires syntax to allow, eg, yacc.host to be specified and to
have it check in the right rpmdb, the cheap dirty answer is to ignore
the build requires for cross and wait for the build error.
Another idea, I think fakeroot would be super good for accessing the
target arch chroots. For example that way your build user can automate
refresh of the libs and -devel stuff in the chroot, ie, you rebuild
libblah for a traget arch, and after a successful build libblah.arch and
libblah-devel.arch are rpm -Uvf'd into the arch chroot using fakeroot as
part of a cross build script, without needing true root.
-Andy
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
