5

As I've been getting into embedded systems I've noticed that some projects (Arch Arm and OpenBSD for example) frown upon cross compiling. What is the reasoning for this? Is a cross-compiled binary somehow different from a natively compiled one?

OpenBSD suggests that building on the hardware ensures that the system is fully functional (and also self-hosting) and that makes complete sense. But do people actually develop and compile kernel drivers on the hardware they are developing for? It sounds very time consuming.

From OpenBSD FAQ:

"Cross-compiling tools are in the system, for use by developers bringing up a new platform. However, they are not maintained for general use."

-http://www.openbsd.org/faq/faq5.html#ProbXComp

I'll see if I can hunt down the IRC log where a developer from ArchLinux Arm told me that they don't cross compile, though they seem to have updated their info on cross-compiling with DistCC: http://archlinuxarm.org/developers/distcc-cross-compiling

  • Perhaps they are being lazy and dont want to support it? – old_timer Feb 24 '14 at 15:02
  • Links to the "frown on"? Also is there a difference in license applied to statically linked libraries on the two systems? – user40980 Feb 24 '14 at 15:10
  • Primarily a guess, but I think the OpenBSD developers also use the build process as a test to see if the target system is capable of running the OS and user programs with a reasonable user experience. – Bart van Ingen Schenau Feb 24 '14 at 15:42
  • @BartvanIngenSchenau I think you're right about that, but do they do normal kernel development (drivers, etc) on the system itself or do they just build 'releases' on the actual hardware but develop with a cross toolchain? – tpaul Feb 24 '14 at 16:21
  • I think cross-compiling is pretty standard in embedded systems. Sure, there are systems can can compile themselves, slowly, but I would say they are the exception. If you have references that say otherwise, please show them. – david.pfx Mar 26 '14 at 14:05
1

For projects like Arch Linux ARM and OpenBSD that are trying to build and maintain a complicated, interactive user environment, a strong preference for doing "native builds" (in OpenBSD terminology) forces developers to "eat their own dogfood" and minimizes the MxN problem of maintaining M code generators in N environments.

For an embedded systems project with one target environment and application code under the control of a small group of developers, that reasoning doesn't apply.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.