[CentOS-devel] CentOS-5 Cross-Build Environment (arm, mips, sparc, others..) / pre-alpha released

Tue Jan 15 00:57:23 UTC 2008
Lennert Buytenhek <buytenh at wantstofly.org>

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.