On 12/23/10 13:24, Somebody in the thread at some point said:

Hi -

Thanks for sharing these steps.

You're welcome.

...

4. rpmbuild -ba --define "binutils_target armv5tel-redhat-linux-gnueabi"

rpmbuild/SPECS/gcc.spec

6. rpmbuild -ba --define="cross_target armv5tel-redhat-linux-gnueabi"

rpmbuild/SPECS/gcc.spec

Providing cross_target and binutils_target seems to be a neat solution. However can it be applied to all SRPMs in Fedora universe?

If we can do that, then building packages for ARM would be faster I guess. ( I am not aware of various issues with buidling RPMs using cross compilers. )

Well, the blah_target macros are cheats, actually the spec files for those two particularly look for them and act quite differently if they're defined. It has to be done like that because in those cases in fact we're cooking host executables which happen to be configured for ARM; they're x86_64 executables and packages coming out still at the end for example. They're not actually cross compilation actions which would result in an armv5tel package coming out of an x86_64 host.

What you can do generically with rpmbuild for cross is use the --target=<arch> option to really get it to cross build and issue <arch> packages instead of host ones. I used this successfully to package the cross-built bootloader and kernel for an ARM Fedora-based device earlier in the year.

Many packages will eat that OK as well for cross build, it gets passed into ./configure and if the package is capable to configure itself to cross build it will do so.

However there are enough packages like perl that cannot cleanly build cross (it likes to build a "miniperl" executable with which it completes the build action; the cross-built miniperl won't work on the host) and enough problems from staging cross package installs (%pre and %post don't work) that you are way better off doing native build and reserving cross for stuff that really needs it like bootloader and kernel.

-Andy