LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Embedded & Single-board computer (https://www.linuxquestions.org/questions/linux-embedded-and-single-board-computer-78/)
-   -   Where can I download arm-linux-* toolchain ? (https://www.linuxquestions.org/questions/linux-embedded-and-single-board-computer-78/where-can-i-download-arm-linux-%2A-toolchain-871053/)

unimous 03-25-2011 10:01 PM

Where can I download arm-linux-* toolchain ?
 
I wander where to download arm-linux-* toolchain?

I have found two website:

[1].http://www.arm.linux.org.uk/, but the toolchain is too old.

[2].http://www.gnuarm.com/, but the toolchian's name is arm-elf-*, not arm-linux-*, are they the same?

Is there an official organization who maintain the cross toolchain, and who is he?

corp769 03-25-2011 10:16 PM

It looks like http://www.gnuarm.com/ should be it.

knudfl 03-26-2011 05:16 AM

The only recommended tool chain is "crosstool-ng"

Other tools are poorly maintained or not maintained at all.

http://ymorin.is-a-geek.org/dokuwiki/projects/crosstool

http://ymorin.is-a-geek.org/download...1.10.0.tar.bz2

corp769 03-26-2011 05:17 AM

Quote:

Originally Posted by knudfl (Post 4303919)
The only recommended tool chain is "crosstool-ng"

Other tools are poorly maintained or not maintained at all.

http://ymorin.is-a-geek.org/dokuwiki/projects/crosstool

http://ymorin.is-a-geek.org/download...1.10.0.tar.bz2

Ooo, thanks for that. I didn't come across that one.

cnxsoft 03-28-2011 12:21 AM

If you are using Ubuntu, the easiest way is probably to install the Linaro ARM cross-compiler

https://wiki.linaro.org/Resources/ToolchainInstall

PoleStar 03-29-2011 02:00 PM

I use fedora, they have a "cross" repository. After adding that you can have all this

Code:


[co@localhost ~]$ armv5tel-redhat-linux-gnueabi-
armv5tel-redhat-linux-gnueabi-addr2line  armv5tel-redhat-linux-gnueabi-gcc        armv5tel-redhat-linux-gnueabi-objcopy
armv5tel-redhat-linux-gnueabi-ar        armv5tel-redhat-linux-gnueabi-gcov      armv5tel-redhat-linux-gnueabi-objdump
armv5tel-redhat-linux-gnueabi-as        armv5tel-redhat-linux-gnueabi-gdb        armv5tel-redhat-linux-gnueabi-ranlib
armv5tel-redhat-linux-gnueabi-c89        armv5tel-redhat-linux-gnueabi-gdbtui    armv5tel-redhat-linux-gnueabi-readelf
armv5tel-redhat-linux-gnueabi-c99        armv5tel-redhat-linux-gnueabi-gprof      armv5tel-redhat-linux-gnueabi-run
armv5tel-redhat-linux-gnueabi-cc        armv5tel-redhat-linux-gnueabi-gstack    armv5tel-redhat-linux-gnueabi-size
armv5tel-redhat-linux-gnueabi-c++filt    armv5tel-redhat-linux-gnueabi-ld        armv5tel-redhat-linux-gnueabi-strings
armv5tel-redhat-linux-gnueabi-cpp        armv5tel-redhat-linux-gnueabi-nm        armv5tel-redhat-linux-gnueabi-strip

not bad eh?

theNbomr 04-05-2011 06:45 PM

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.

--- rod.

littlebigman 04-07-2013 05:36 PM

I need a toolchain to cross-compile applications for the armv5tel processor used in the SheevaPlug.

Do I really must learn how to build a whole toolchain myself, or is there a binary toolchain already available somewhere?

Thank you.

theNbomr 04-07-2013 07:21 PM

There is evidently a suitable cross toolchain available from a Ubuntu repository . A little Google searching should turn up a download method.
--- rod.

littlebigman 04-08-2013 07:15 AM

Thanks. It took a bit more than a little Googling to sort through old/incomplete/vague pages on the subject.

Turns out the toolchain is available here ("Host SW Support Package For Linux"):
http://www.plugcomputer.org/downloads/plug-basic/

However, no documentation is provided to explain what to do with the two directories it contains:
gcc/
rootfsv1.0/

How to go from this to a running "Hello, World!"?

Thank you.

goumba 04-08-2013 07:29 AM

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.

littlebigman 04-08-2013 08:17 AM

Thanks.

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.

Wouldn't it be a better idea to use the cross-compiler provided by Marvell instead?

goumba 04-08-2013 08:48 AM

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.

littlebigman 04-08-2013 09:47 AM

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?

Thank you.

theNbomr 04-08-2013 10:13 AM

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.

--- rod.

littlebigman 04-08-2013 04:43 PM

Thanks a lot for the education. That explains why Linus isn't happy about supporting ARM in Linux.

BTW, I noticed something strange: After unzipping the toolchain, I simply cd'ed to ./bin and ran "./arm-none-linux-gnueabi-gcc -o hello hello.c", which built a statically-linked binary without my telling it where to find the include + library.

Does it work because the compiler expects those two items to be located in ../include and ../lib, respectively?

Code:

/home/joe/Downloads/LinuxHost/gcc/bin# ./arm-none-linux-gnueabi-gcc -o hello hello.c

/home/joe/Downloads/LinuxHost/gcc/bin# file hello
hello: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.14, not stripped

/home/joe/Downloads/LinuxHost/gcc/bin# ./arm-none-linux-gnueabi-readelf -s hello

Symbol table '.dynsym' contains 5 entries:
  Num:    Value  Size Type    Bind  Vis      Ndx Name
    0: 00000000    0 NOTYPE  LOCAL  DEFAULT  UND
    1: 0000829c  1000 FUNC    GLOBAL DEFAULT  UND abort@GLIBC_2.4 (2)
    2: 000082a8  592 FUNC    GLOBAL DEFAULT  UND __libc_start_main@GLIBC_2.4 (2)
    3: 00000000    0 NOTYPE  WEAK  DEFAULT  UND __gmon_start__
    4: 000082c0  740 FUNC    GLOBAL DEFAULT  UND puts@GLIBC_2.4 (2)


/home/joe/Downloads/LinuxHost/gcc/bin# ldd ./hello
        not a dynamic executable

/home/joe/Downloads/LinuxHost/gcc# ll
drwxr-xr-x  6 fred fred 4096 Feb 26  2008 arm-none-linux-gnueabi/
drwxr-xr-x  2 fred fred 4096 Apr  8 22:29 bin/
drwxr-xr-x  3 fred fred 4096 Feb 26  2008 distributed/
drwxr-xr-x  2 fred fred 4096 Feb 26  2008 include/
drwxr-xr-x  2 fred fred 4096 Feb 26  2008 info/
drwxr-xr-x  3 fred fred 4096 Feb 26  2008 lib/
drwxr-xr-x  3 fred fred 4096 Feb 26  2008 libexec/
drwxr-xr-x  4 fred fred 4096 Feb 26  2008 man/
drwxr-xr-x  8 fred fred 4096 Feb 26  2008 share/


theNbomr 04-08-2013 05:14 PM

Quote:

Originally Posted by littlebigman (Post 4927794)
Does it work because the compiler expects those two items to be located in ../include and ../lib, respectively?

Most likely. You can confirm this by running
Code:

./arm-none-linux-gnueabi-gcc -print-search-dirs
Depending on the toolchain builder, the sysroot can be absolute or relative to the compiler. Re-arranging stuff can get you into a significant pickle.
There are some other interesting things that the compiler will spit out. Use the --help option for some suggestions.

--- rod.

littlebigman 04-11-2013 10:34 AM

Thanks much for the infos.

Here's the output of -print-search-dirs:
Code:

install: /root/LinuxHost/gcc/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.1/
programs: =/root/LinuxHost/gcc/bin/../libexec/gcc/arm-none-linux-gnueabi/4.2.1/:/root/LinuxHost/gcc/bin/../libexec/gcc/:/root/LinuxHost/gcc/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.1/../../../../arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi/4.2.1/:/root/LinuxHost/gcc/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.1/../../../../arm-none-linux-gnueabi/bin/
libraries: =/root/LinuxHost/gcc/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.1/:/root/LinuxHost/gcc/bin/../lib/gcc/:/root/LinuxHost/gcc/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.1/../../../../arm-none-linux-gnueabi/lib/arm-none-linux-gnueabi/4.2.1/:/root/LinuxHost/gcc/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.1/../../../../arm-none-linux-gnueabi/lib/:/root/LinuxHost/gcc/bin/../arm-none-linux-gnueabi/libc/lib/arm-none-linux-gnueabi/4.2.1/:/root/LinuxHost/gcc/bin/../arm-none-linux-gnueabi/libc/lib/:/root/LinuxHost/gcc/bin/../arm-none-linux-gnueabi/libc/usr/lib/arm-none-linux-gnueabi/4.2.1/:/root/LinuxHost/gcc/bin/../arm-none-linux-gnueabi/libc/usr/lib/

At this point, I'm playing with the binary toolchain provided by Marvell.

If some application doesn't compile or work as planned, I'll check how to build my own toolchain with eg. Crosstool-NG, Buildroot, ELDK, Linaro, etc.

littlebigman 04-11-2013 10:45 AM

Another thing I wonder: When cross-compiling an application because its authors didn't port it yet, is there a way to be positive the application will run safely, especially on platforms like ARM that come in very different shades?

I'm thinking of memory leaks or code that will simply crash because it was only ever tested on x86 hosts and wasn't rewritten specifically for other CPU's like the ARM.

theNbomr 04-11-2013 11:35 AM

Quote:

Originally Posted by littlebigman (Post 4929783)
Another thing I wonder: When cross-compiling an application because its authors didn't port it yet, is there a way to be positive the application will run safely, especially on platforms like ARM that come in very different shades?

I'm thinking of memory leaks or code that will simply crash because it was only ever tested on x86 hosts and wasn't rewritten specifically for other CPU's like the ARM.

AFAIK, it is so far impossible to be positive any code is bug free whether the bugs are related to porting issues or any other reason. There are lots of ways to include architecture dependent code, such as assumed endian-ness, IO mapping, etc. I don't know if there is any easy way to identify such constructs reliably. Thorough scrutiny of the source code is probably your best bet. I have used many open source packages built from source tarballs without any problem. I've also used a few that did have problems, most of which I never found the causes of.

--- rod.

littlebigman 04-12-2013 08:43 AM

Thanks Rod. I'll see how it goes.


All times are GMT -5. The time now is 04:03 AM.