User: Password:
|
|
Subscribe / Log in / New account

Fedora mulls ARM as a primary architecture

Fedora mulls ARM as a primary architecture

Posted Mar 22, 2012 13:16 UTC (Thu) by hanwen (subscriber, #4329)
In reply to: Fedora mulls ARM as a primary architecture by slashdot
Parent article: Fedora mulls ARM as a primary architecture

if a build system tries to execute a program it builds (= it's broken)

I've written a lot of code to make common linux packages cross-compile, and I think the fedora team is completely right to avoid it.

Packages that build and execute stuff to build are broken for cross-compile, but unfortunately, they are also exceedingly common. Any package that is some sort of platform needs to read its own platform definitions/programs, either to prepare the platform or to document it. Examples: ghostscript, python (and all other interpreters), every compiler (look at the horrendous 3 phase build of GCC), document processing (eg. LaTeX), programs that work with interface definitions (like protocol buffers and IDL files). You can run all these binaries on an emulator, but that will hardly be faster than running on the target system to start with.

Getting packages to work for cross compiling is a painful process of infinite recompiles, where you have to figure which parameters (eg. the ones from autoconf configure) should come from the target, and which ones from the host, then the same for the object files. Root cause of the problem are the make/autoconf build tools that work on arbitrary files and arbitrary variables, so the distinction between host and target is not made explicit.


(Log in to post comments)

Fedora mulls ARM as a primary architecture

Posted Mar 22, 2012 13:36 UTC (Thu) by dlang (subscriber, #313) [Link]

go read rob landley's blog http://landley.net/notes.html for a peek into the horror story that cross compiling, and even trying to compile with qemu can run into. doing this for an entire distro seems like a risky thing.

That being said, I am amazed that anything more than a one-person distro isn't using distcc or similar to spread the compile load over a farm of machines.

Getting lots of ARM machines for this sort of thing is pretty easy, and power wise is far more efficient than any x86 machine. People make off-the-shelf boxes which have dozens of ARM SoC systems plugged into them. individually they are poor, but as a compile farm they would be very efficient (the final serialized link step would still be a bottleneck, but that's a small part of the overall CPU time)

Fedora mulls ARM as a primary architecture

Posted Mar 22, 2012 15:10 UTC (Thu) by rwmj (guest, #5474) [Link]

There's no problem using distcc (in fact, it's fairly trivial to add).

The problem is that you get hit by Amdahl's law: single builds are simply not very parallelizable. Recursive Makefiles have to be run sequentially. Even a large project may only have dozens of C files, but to really exploit multicore ARM you need hundreds of parallel tasks. Tests have to run sequentially (at least, they do when using automake). There's a fixed "top and tail" overhead of unpacking the tarball and constructing the final package.

Fedora mulls ARM as a primary architecture

Posted Mar 22, 2012 15:42 UTC (Thu) by dlang (subscriber, #313) [Link]

The article seemed to be indicating that distcc was receiving almost as much pushback as cross compiling.

as for the "tip and tail" overhead, that's one place where I would say to use a amd64 machine, use it to unpack the tarball onto a network accessible drive and then package up the result. Ideally you do this on the machine providing the network accessible drive so that it's all local I/O.

This isn't going to scale linearly with the number of machines for any one package build, but there are a LOT of packages that need to be built, so overall you should be able to keep dozens, if not hundreds of cores busy.

Fedora mulls ARM as a primary architecture

Posted Mar 22, 2012 19:33 UTC (Thu) by nix (subscriber, #2304) [Link]

Automake grew support for parallel tests in 1.11.

Fedora mulls ARM - Is tar holding us back?

Posted Mar 25, 2012 3:33 UTC (Sun) by ndye (guest, #9947) [Link]

Amdahl's law [shows up in] a fixed "top and tail" overhead of unpacking the tarball . . .

With horizontal scaling defining the future, should we consider an archive format with a random-access catalog (like ZIP) to replace linear tar? (Just an idea.)

Fedora mulls ARM - Is tar holding us back?

Posted Mar 26, 2012 4:19 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

There's Duplicity[1], but AFAICS, it's gone approximately nowhere so far.

[1]http://duplicity.nongnu.org/new_format.html

Fedora mulls ARM as a primary architecture

Posted Apr 4, 2012 19:53 UTC (Wed) by cmsj (guest, #55014) [Link]

You also hit cmsj's law, which states that all ARM hardware is fundamentally opposed at a sub-atomic level, to the calm and peaceful mental state of sysadmins ;)

(which is to say that all of the currently available ARM hardware is extremely unreliable under continuous duress, and none of the hardware is built for low friction remote management. This will change when ARM servers are a real thing, but for now I welcome the work being done by Linaro folks to enable Ubuntu building ARM packages with qemu!)

Fedora mulls ARM as a primary architecture

Posted Mar 22, 2012 15:34 UTC (Thu) by slashdot (guest, #22014) [Link]

Most of the build time is of course spent running gcc and ld, so even if you have to run everything else in an emulator, it's still likely much faster.

Fedora mulls ARM as a primary architecture

Posted Mar 22, 2012 20:42 UTC (Thu) by oak (guest, #2786) [Link]

GCC takes a lot of time, especially for C++, but all the autotools stuff, package management etc take also surprising amount of time. With small software packages that's significantly more time than what the compiler takes, with larger packages, it can still be several tens of percents.

Scratchbox2 is designed to deal also with that:
http://maemo.gitorious.org/scratchbox2

It uses LD_PRELOAD and other techniques to map file accesses to host binaries, runs cross-compiled code through Qemu (again, with path mapping) and so on. It's used by Tizen, MeeGo's Mer successor, was available for building Maemo stuff is and packaged in Debian (since Lenny) & Ubuntu (since Hardy).

Fedora mulls ARM as a primary architecture

Posted Mar 22, 2012 16:02 UTC (Thu) by pboddie (guest, #50784) [Link]

CPython's build process is broken for cross-compilation and despite various patches to fix it, there's no interest amongst the core developers in doing much about the situation, unfortunately.

There's actually hardly any reason to do what the Python build process does, which is to run the built executable in order to perform a bunch of tasks that could in many cases be done by a suitable host-native executable: compiling .py files to .pyc files merely demands an executable supporting the same Python version, not the specific executable to be run in the target environment; copying files into a particular location does not depend on executing ARM code just because the target device happens to use an ARM CPU.


Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds