On Fri, 2007-06-15 at 07:01 +0100, Andy Green wrote:
> 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).
Typo: s/arch/noarch/
> >> 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.
I prefer using <target>-gcc-*.i386.rpm
If sys-rooting such a toolchain, it's toolchain's target-libs could be packaged into a
<target>-sys-root-*.noarch.rpm
Due to rpm's limitations, this isn't easy to implement with "one-tree
style builts" (building GCC and libc in one build run) of a toolchain,
but it is pretty straight forward, when repackaging target-library
binaries or building a toolchain incrementally.
> >> 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
If I understand you correctly the problem you are referring to is
separating "tools being used at build-time on the host" from
"tools being used at run-time on the target".
(Classic situation: building inserts hard-coded directories/paths
referring to files on the build-host into target-files)
Yes, this is a problem. I am not aware about a general solution nor do I
have solution, either.
> -- 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.
This is a different problem, it's cross-"rpmbuild-ing"
target-native-rpms. The result would be a *.<target>.rpm.
What I am doing is aiming at cross-building target-binaries, not target
packages/rpms.
> 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.
Ralf
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
