Where can I download arm-linux-* toolchain ?

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?

/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/

Originally Posted by littlebigman 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

./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.

Thanks much for the infos.

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

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.

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.

Originally Posted by littlebigman 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.

Thanks Rod. I'll see how it goes.