Linux - Embedded & Single-board computerThis forum is for the discussion of Linux on both embedded devices and single-board computers (such as the Raspberry Pi, BeagleBoard and PandaBoard). Discussions involving Arduino, plug computers and other micro-controller like devices are also welcome.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
From my experience, there are so many permutations and combinations of Arm configurations (ABI: old vs new, floating point math: soft vs hardware, endianness, Arm versions/models, etc.), as well as building against various kernel headers, C library, and so on, that it is almost impossible to find a ready-made version that works perfectly with your hardware and OS. Building your own can also be somewhat painful, but Crosstool-NG is as good a tool as you'll find for building a cross toolchain.
I am running Debian, but if I search in Synaptic, it turns up plenty of packages related to arm development. If you search for "arm" by "Name", scroll down a bit until you find the gcc packages. Select the appropriate packages and it should pull in the necessary ccp, binutils, etc. You should be able to do the same on Ubuntu.
I tried this on the PC I intend to use to cross-compile applications for the SheevaPlug:
# apt-cache search arm gcc
cpp-4.6-arm-linux-gnueabi - GNU C preprocessor
cpp-4.6-arm-linux-gnueabihf - GNU C preprocessor
cpp-4.7-arm-linux-gnueabi - GNU C preprocessor
cpp-4.7-arm-linux-gnueabihf - GNU C preprocessor
cpp-arm-linux-gnueabi - The GNU C preprocessor (cpp) for armel architecture
cpp-arm-linux-gnueabihf - The GNU C preprocessor (cpp) for armhf architecture
gcc-4.6-arm-linux-gnueabi - GNU C compiler
gcc-4.6-arm-linux-gnueabi-base - GCC, the GNU Compiler Collection (base package)
gcc-4.6-arm-linux-gnueabihf - GNU C compiler
gcc-4.6-arm-linux-gnueabihf-base - GCC, the GNU Compiler Collection (base package)
gcc-4.6-multilib-arm-linux-gnueabi - GNU C compiler (multilib files)
gcc-4.6-multilib-arm-linux-gnueabihf - GNU C compiler (multilib files)
gcc-4.7-arm-linux-gnueabi - GNU C compiler
gcc-4.7-arm-linux-gnueabi-base - GCC, the GNU Compiler Collection (base package)
gcc-4.7-arm-linux-gnueabihf - GNU C compiler
gcc-4.7-arm-linux-gnueabihf-base - GCC, the GNU Compiler Collection (base package)
gcc-4.7-multilib-arm-linux-gnueabi - GNU C compiler (multilib files)
gcc-4.7-multilib-arm-linux-gnueabihf - GNU C compiler (multilib files)
gcc-arm-linux-gnueabi - The GNU C compiler for armel architecture
gcc-arm-linux-gnueabihf - The GNU C compiler for armhf architecture
gccgo-4.7-arm-linux-gnueabi - GNU Go compiler
gccgo-4.7-arm-linux-gnueabihf - GNU Go compiler
gfortran-arm-linux-gnueabi - The GNU Fortran 95 compiler for armel architecture
gfortran-arm-linux-gnueabihf - The GNU Fortran 95 compiler for armhf architecture
gobjc++-arm-linux-gnueabi - The GNU Objective-C++ compiler for armel architecture
gobjc++-arm-linux-gnueabihf - The GNU Objective-C++ compiler for armhf architecture
gobjc-arm-linux-gnueabi - The GNU Objective-C compiler for armel architecture
gobjc-arm-linux-gnueabihf - The GNU Objective-C compiler for armhf architecture
libgcc1-armel-cross - GCC support library
libgcc1-armhf-cross - GCC support library
libgcc1-dbg-armel-cross - GCC support library (debug symbols)
libgcc1-dbg-armhf-cross - GCC support library (debug symbols)
libhfgcc1-armel-cross - GCC support library (hard float ABI)
libhfgcc1-dbg-armel-cross - GCC support library (debug symbols)
libsfgcc1-armhf-cross - GCC support library (soft float ABI)
libsfgcc1-dbg-armhf-cross - GCC support library (debug symbols)
I have no idea what to install to compile code for the ARMv5TE that the Plug uses.
If you use the file from Marvell, it appears that the gcc.tar.bz2 has the toolchain you're looking for. Extract it, and add the (path)/bin to your PATH. Then use the appropriate directories for include and libs when building.
Thanks. I'd rather use the toolchain provided by Marvell, and install another toolchain if it doesn't work.
I successfully compiled and ran "Hello, World".
Am I correct in understanding that cross-compiling an application basically means:
1. Editing PATH once so the build process knows where to find the toolchain
2. Using the right path in "./configure" so it knows where to find the includes/libraries?
Also, any idea why Marvell also packed a root fs in the toolchain ZIP?
Much of the toolchain requires library files, headers, and sundry other components in order to work. The convention for cross toolchains is to put these in a skeleton filesystem that is part of the toolchain. This is known as 'sysroot'. Sometimes a toolchain gets built with a hardcoded expectation of where the sysroot is installed, and this may not match your requirements. Also, the components of the sysroot should be an exact or very close match to the respective components on the actual target host.
You need to know something about the target host architecture software (libc, libm, etc.) to make sure this is the case. Sadly, there is a very large universe of possible mismatches in the ARM architecture. 'Hello World' may run just fine, but other more complex code may fail in strange ways. This accounts for the plethora of gcc's found in the repository someone posted.
The list of compatibility issues includes (but not limited to):
endian-ness - little, big
ABI - old, enhanced
math - FPU (which), emulated, software
ARM architecture - ArmX
Standard C lib version
Threading model - POSIX, Linuxthreads
Every CPU, and every board implementation has its particular idiosyncrasies, and the toolchain should match these. Vendor-supplied toolchains can be the best way to go, although these aren't always the best either.
Using the toolchain to build packages with the usual 'configure; make; make install' routine can frequently be accomplished by pointing $PATH to the cross toolchain binary directory, as well as providing the correct '--host=xxxxx' toolchain prefix to the configure script.