On Mon, Jan 14, 2008 at 02:21:06AM +0100, Brian Schueler wrote:
I've begun to work on a cross-build environment hopely to make CentOS 5 run on other architectures than supported by CentOS yet and that supported by the PNAELV.
Fedora, CentOS, Debian and the like do not really lend themselves well for cross-compiling. Even if you do fix most of the package issues and packaging issues so that cross compiling will work, upstream will end up breaking stuff faster than you'll be able to fix it.
When I did the initial port of Debian to ARM EABI, I bootstrapped by taking an OpenEmbedded root filesystem, and gradually building more and more Debian packages on top of that. I think such an approach is probably more effective (in terms of time spent) than trying to make each and every Debian/CentOS/Fedora package cross-compile-able.
This project comes with a patch for the glibc 2.5 with added support for architectures like arm, mips, ppc, alpha, etc. to generate a cross-compile toolchain (cross-compilers, assemblers, linker/loader).
There is an x86->ARM cross toolchain built from Fedora sources available at:
http://ftp.linux.org.uk/pub/linux/arm/fedora/cross/
The patches pretty much only touch the packaging side of things, and manage to build both userland apps and kernels.
Many RPMs does cross-build very well, but others fails on sanity checks, incompatible configure scripts, etc. (Kernel compilation is not included at this time.)
In the case of Debian or Fedora, even if 90% cross-builds fine and only 10% of packages doesn't cross-build out of the box, the amount of time and effort required to maintain such a solution is _huge_. (And forking off the entire distro at one static point to apply your cross fix patches to it is not a very interesting value proposition.)
I want to switch to 'mock' and - I need a lot of help with its internals. The best enhancement were that 'mock' could recursively rebuild software entirely from source (using a yum repository that _only_ provides SRPMS).
There is 'thetango', which is a tool that is intended to help with bootstrapping an SRPM collection, and tries to (given a set of SRPMS) come up with a build order for those SRPMS that meets build dependencies. I haven't used it myself, so I'm not sure how well it works.