Hello all,

My post is pretty long and I have quite a few questions. If you feel the need to tell me to RTFM, please _do_, only link to the manuals I need to read!

Recently I have been noticing interest in ARM, due to the likes of the Raspberry Pi, BeagleBone, and friends. In particular, the RPI seems to be lacking a distribution which packages binaries compiled with the armhf "hard float" support for ARMv6. (I believe Debian and Ubuntu are aiming to ship such software, only for ARMv7 chips.)

I am pretty new to compilers, toolchains and cross-compiling. However I have used SDKs from Palm and Apple which use cross compilers (GCC) to target ARM for C/C++. I know there are "gotchas" to look out for, such as word size, instruction set, endianness, etc. Also, much *nix software is shipped with a "configure" script which attempts to build makefiles and other scripts and assets so as to match the host environment, because the assumption is that the host and target machines are one and the same. So obviously the naive "configure && make && make install" is out of the question.

My real question is why do some distributions, such as Debian and Fedora, have a policy of building packages only with a native toolchain? (Ie., the distribution's packages must be built on the architecture for deployment.)

Is there no effort to sanitize the build environment such that it is as much as possible not dependent on irrelevant system state? Don't pbuilder and the like accomplish this?

And I suppose, what I would really like to know is, how close must the environments be? If I build a gnu toolchain on a posix system (like darwin) on e.g. an ARM Cortex A8 (ARMv7) architecture, could it be safely used to build Linux binaries for the same hardware?

Also, if I want to do "native" compilation with the same software environment (E.g. build debian packages on a debian system), is it sufficient (and necessary?) for the host arch instruction set to be a superset of the target arch's instruction set, given that they have the same endianness and word size?

If you can provide any answers, whether technological, or more political/traditional/historical, I am eager to hear. I know I am asking a lot, but I am reading a lot, and I don't know how many of these are issues with distributions, or the GNU toolchain, or hardware or whatever. Please help me look in the right direction!

Kind Regards,
Tim

Cross development isn't too difficult once you have a good, working cross toolchain. Creating one (or more than one) is the hard part. It's hard for a few reasons:

• There are a lot of components that all have to work together, and every one of them has a bunch of different versions.
• There are a lot of different target architectures, and each with particular differences. Problem-squared for Arm architecture.
• You have to start out from something that is normally expecting to build native code. Some of the things you are building want to be installed over top of the things you're using to build them. Getting things wrong can have very bad effects.
• It's a big thing to build, and needs a lot of time, effort, disk space and CPU cycles just to perform a fully-working toolchain build.

There are just way too many possible cross toolchain configurations for anyone to be able to provide a universal selection. So there are tools like Crosstool-NG that do a good job of taking the pain out of the process. Even using such a tool, you will need to have some patience, persistence, and probably some help.

A correctly built cross toolchain will be absolutely un-influenced by its host architecture. It doesn't matter whether the build host is Linux-x86-64 or Solaris-Sparc or.... The target binaries produced should be identical, using a cross toolchain with identical components, but running on different build host architectures. Having said this, it is probably difficult to get a set of identical toolchain components to build on different build hosts.

As I started out by saying, one you've got a working toolchain, cross-compiling isn't too much different form doing native builds. One of the big headaches is not the lack of cross toolchains in Linux distros, but the expectation by many FOSS developers that their code will always be built using native build tools. The 'configure' step is usually littered with build-host dependencies. This can add a lot of grief to developers. Also, dependency-hell becomes a lot more annoying.

Still think you want to do cross development?
--- rod.

Ok, so if I understand you correctly,

Setting up the cross toolchain is difficult, but doable. Apple, Palm, and others have had little reason not to leverage cross development because SDKs and apps written for them are designed for cross development; I.e., they don't poke around the host environment to figure out how something should be built.

If done correctly, the binaries produced by a cross toolchain should be indistinguishable from natively-built binaries.

Its harder in the case of FOSS, because of the hard-coded host environment dependencies in configure scripts, makefiles, and the like.

Distributions may introduce more host dependencies, or at least not mitigate the ones from upstream.

So, in summary, building binaries with a cross toolchain is hard, but packaging (e.g. making .debs) FOSS software on one arch for another is harder.

I think that's about right. Not sure what you mean by
I think most cross-development get done in the embedded systems world. There, I don't think there is much emphasis or motivation to be creating packages like .debs and .rpms. Most people that do cross development have custom, proprietary, or at least small target applications. Also, most people doing cross development are pretty comfortable build applications from sources, so if there is some kind of distribution channel, it gets done that way.

I rarely think about any comparison to natively built applications for most targets. The reason I want to do cross development is usually because the target platform is unsuitable for doing development work. Otherwise, what you say is generally true.

--- rod.

Well Ubuntu and Debian have ported their distributions to ARMv7, but apparently require building of binaries (and packaging?) to be done natively. I was just trying to play the Devil's advocate and ask why this is so.

I think that is simply the standard format for Linux distributions. To put it another way, if someone produced a distribution for any architecture, and you wanted the development system to be non-native, then the universe of possible development/build architectures is very large, and I don't know how you would choose which cross development platform to support. Multiply that by all of the supported architectures, and the matrix of runtime & development architectures becomes unmanageable.

--- rod.