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.
Notices
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.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
There is evidently a suitable cross toolchain available from a Ubuntu repository . A little Google searching should turn up a download method.
--- rod.
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:
Code:
# 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.
gcc-4.7-arm-linux-gnueabi looks like the one you want. It's for endian little processors.
According to http://infocenter.arm.com/help/index.../BABJCGCF.html, the processor supports both, but legacy support for big endian. Check out that page, it specifies compiler options you may need to know, even if you use their toolchain.
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.