Cross Compiling Options
What is your strategy on cross compilation toolchains? Here we explore a
few options:
- DIY - requires you to manually start each step, unless you're comfortable enough to script the process. As each step takes ages, this can be a tedious job. However, it gives you full control and insight into each step.
- crosstool [http://www.kegel.com/crosstool/] - a scripted version of DIY + patches. Used to be my preferred tool, but hasn't been updated since 2006. Limited to glibc.
- crosstool-NG [http://ymorin.is-a-geek.org/projects/crosstool] - a rewrite of crosstool. Provides a menuconfig configuration interface, which makes it quite easy to use. You can also pass configurations around. Supports glibc, but also uclibc and eglibc.
- buildroot [http://buildroot.uclibc.org/] - builds a uclibc-based gcc in the process of building an entire system. The toolchain can be ripped out (you can also force buildroot to use an external toolchain - thus avoiding building the same toolchain over and over again). As the focus is on the entire system, this approach provides little insight of the toolchain, but in my experience, the outcome usually works well.
- scratchbox [http://www.scratchbox.org/] - provides uclibc or glibc based toolchains. Approaches cross compilation is a new way - providing an environment where the actual cross part of the compilation is abstracted away. Also provides an emulated target environment, so you can run your ARM binaries on your standard PC from within the scratchbox environment.
The available options are ordered in some sort of control freak factor order, where DIY provides loads of control over every tiny aspect, while scratchbox just makes things work.
Myself? Last time around I used ct-ng, but I've used them all (and will not DIY again unless forced ;) ).
Johan Thelin is a consultant working with Qt, embedded and free
software. On-line, he is known as e8johan.
Today’s modular x86 servers are compute-centric, designed as a least common denominator to support a wide range of IT workloads. Those generic, virtualized IT workloads have much different resource optimization requirements than hyperscale and cloud applications. They have resulted in a “one size fits all” enterprise IT architecture that is not optimized for a specific set of IT workloads, and especially not emerging hyperscale workloads, such as web applications, big data, and object storage. In this report, you will learn how shifting the focus from traditional compute-centric IT architectures to an innovative disaggregated fabric-based architecture can optimize and scale your data center.
Sponsored by AMD
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
| Making Linux and Android Get Along (It's Not as Hard as It Sounds) | May 16, 2013 |
| Drupal Is a Framework: Why Everyone Needs to Understand This | May 15, 2013 |
| Home, My Backup Data Center | May 13, 2013 |
| Non-Linux FOSS: Seashore | May 10, 2013 |
| Trying to Tame the Tablet | May 08, 2013 |
| Dart: a New Web Programming Experience | May 07, 2013 |
- RSS Feeds
- New Products
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Drupal Is a Framework: Why Everyone Needs to Understand This
- Home, My Backup Data Center
- A Topic for Discussion - Open Source Feature-Richness?
- What's the tweeting protocol?
- Dart: a New Web Programming Experience
- Developer Poll
- Trying to Tame the Tablet
- Reply to comment | Linux Journal
1 hour 25 min ago - Reply to comment | Linux Journal
3 hours 58 min ago - Reply to comment | Linux Journal
5 hours 15 min ago - great post
5 hours 50 min ago - Google Docs
6 hours 12 min ago - Reply to comment | Linux Journal
11 hours 1 min ago - Reply to comment | Linux Journal
11 hours 48 min ago - Web Hosting IQ
13 hours 22 min ago - Thanks for taking the time to
14 hours 58 min ago - Linux is good
16 hours 56 min ago



Comments
In my opinion, Openembedded
In my opinion, Openembedded is also a good option to be mentioned here? With openembedded you can generate installable cross compiler toolchains for many target architectures, besides building complete target images etc. It is very configurable.
I still use crosstool
Kegel's crosstool is still my favorite. Last week I modified it to build absolute latest toolchain combo GCC 4.5.0 + GLIBC 2.11.2 + BINUTILS 2.20 for powerpc32.
Crossplex
I've recently been introduced to Crossplex. While I haven't tried it yet, it looks promising.
MinGW
@BaloneyGeek - you are completely right. As an embedded guy, I kind of completely forgot the OS-to-OS cross compilation needs - especially MinGW. Briefly googling the topic, I ran into a thread where the CT-NG people are discussing adding mingw as a kernel type, thus allowing the build of Windows compatible toolchains from CT-NG.
Johan Thelin is a consultant working with Qt, embedded and free
software. On-line, he is known as e8johan.
Personally I used crosstool
Personally I used crosstool to build a toolchain to build applications that will run on Lantronix's SecureLinx console server (it uses a MIPS-EL processor with glibc - Debian Sarge packages are compatible). For the most part it was a matter of selecting the libc library and cpu type, then sit back and let it build.
For a ppc - uclibc embedded product we have at work I simply used ELDK 4.1 by DENX, which has a complete pre-compiled cross toolchain as well as a root filesystem with a complete build environment for native compilation for the target (if needed). Couldn't get any simpler than that!
DIY is the only way for certain things.
Suppose you were building the MinGW32 or MinGW64 toolchain. DIY would be the only way, unless you wanted to installl your distro packages, which'd always be somehow half broken anyway, or use the mingwmsvc- target which never seems to work out.