Try to reproduce 6 months later and something's changed.It builds for this engineer but not that one.This is never properly documented, and the docs bit-rot if they exist.Build system generally picks one of each and requires you to use its choices together.non-orthogonal, hard to mix and match toolchain, build scripts, packaging (rpm, dpkg, ipkg/opkg, portage, tarballs), system imaging.buildroot wasn't initially intended to be a distro (embedded variant of Zawinski's law).everything has to know about everything else.Most embedded projects get stuck using old packages, even when you can get all the source.Fixes only go upstream if applied to current.Debugging old versions doesn't help the project.Open source community only cares if you're using current version.Little or no regression testing means bit-rot.Add enough variables (which toolchain, which build scripts, which C library) and you may be the only person with your particular setup. Now add 100 different build environments you could be cross compiling from.Non-x86 gets much less attention than x86 at the best of times.The kernel is the poster child for many eyeballs.The packages that do cross compile don't do it the same way, it's not just ".Building a binary they can't run proves nothing and isn't very interesting. Developers haven't got a test environment to run the result.Installing a binary-only toolchain requiring a root login on their development machine isn't appealing Developers haven't got a cross compiling build environment set up for every possible target.The package developer can't reproduce your bug.Less than 10% of the userbase will ever test it, so it'll break a lot.Implementing cross compiling complicates the heck out of the build system for everybody, to serve less than 10% of the userbase.Most developers barely care about native compiling on non-x86, let alone cross-compiling.It built, it ran, it just didn't work in this one area. The Perl thing mentioned earlier shipped to a customer.Using the wrong " strip" mostly works.Then to run its test suite you need to cross-compile tcl/ expect and install it to the target's root filesystem. You didn't build the source on the target, so you have to copy the source tarball to the target hardware. The test suite is often part of the source.libtool, pkg-config, finding Python, wrong signal numbers for Perl. Asking questions about the host to build programs for the target is crazy when the host and the target are not the same.The design of configure is fundamentally wrong for cross-compiling.Machine type given by the host may not equal target.Install gzip on the host, but not in the target.Hard to remove things the host has, but the target doesn't.Different things in $PATH depending on target or host.Each toolchain has its own headers and libraries.Information leaks between the target and the host.Keeping Multiple Build Contexts Straight.Can you build a current Linux 2.6 Kernel on an Alpha Machine running a 2.2 Kernel with GCC 2.95? If not, you need to cross-compile from a newer system.Minimal subset must be supported for each target.Someone somewhere has to do a certain amount of cross-compiling in order to get a new target up and running.Just software, common PC Hardware and Linux OS.About as fast as native compiling on the host.This talk covers application vs system emulation, native vs cross compiling (and combining the two with distcc), using QEMU, setting up an emulated development environment, real world scalability issues, using the Amazon EC2 Cloud, and building a monster server for under $3k. QEMU is rapidly becoming a category killer in open source emulation software, capable of not only booting a Knoppix CD in a window but booting Linux systems built for ARM, MIPS, PowerPC, SPARC, sh4, and more. Interacting with upstream package maintainersĮmulation allows even casual hobbyist developers to build and test the software they write on multiple hardware platforms from the comfort of their own laptop.Using your emulated development environment How to put together a development environment Package management and accidental distros.Building a development environment from source.Prebuilt binaries, or build from source?.Obtaining a development environment for QEMU Disadvantages of native compiling on real hardware.Advantages of native compiling on real hardware.Developing for non-x86 targets using QEMU Rob Landley and Mark Miller Impact Linux, LLC Saturday, September 26, 2009Ĭross compiling, native compiling, and the third option
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |