LinuxQuestions.org
Register a domain and help support LQ
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Hardware > Linux - Embedded & Single-board computer
User Name
Password
Linux - Embedded & Single-board computer This 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

Reply
 
Search this Thread
Old 04-08-2013, 04:43 PM   #16
littlebigman
Member
 
Registered: Aug 2008
Posts: 461

Rep: Reputation: 32

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/
 
Click here to see the post LQ members have rated as the most helpful post in this thread.
Old 04-08-2013, 05:14 PM   #17
theNbomr
LQ 5k Club
 
Registered: Aug 2005
Distribution: OpenSuse, Fedora, Redhat, Debian
Posts: 5,395
Blog Entries: 2

Rep: Reputation: 903Reputation: 903Reputation: 903Reputation: 903Reputation: 903Reputation: 903Reputation: 903Reputation: 903
Quote:
Originally Posted by littlebigman View Post
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.

Last edited by theNbomr; 04-08-2013 at 05:16 PM.
 
Old 04-11-2013, 10:34 AM   #18
littlebigman
Member
 
Registered: Aug 2008
Posts: 461

Rep: Reputation: 32
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.

Last edited by littlebigman; 04-11-2013 at 10:38 AM.
 
Old 04-11-2013, 10:45 AM   #19
littlebigman
Member
 
Registered: Aug 2008
Posts: 461

Rep: Reputation: 32
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.
 
Old 04-11-2013, 11:35 AM   #20
theNbomr
LQ 5k Club
 
Registered: Aug 2005
Distribution: OpenSuse, Fedora, Redhat, Debian
Posts: 5,395
Blog Entries: 2

Rep: Reputation: 903Reputation: 903Reputation: 903Reputation: 903Reputation: 903Reputation: 903Reputation: 903Reputation: 903
Quote:
Originally Posted by littlebigman View Post
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.
 
Old 04-12-2013, 08:43 AM   #21
littlebigman
Member
 
Registered: Aug 2008
Posts: 461

Rep: Reputation: 32
Thanks Rod. I'll see how it goes.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
LXer: GNU ARM toolchain embedded development on Linux LXer Syndicated Linux News 0 05-22-2009 07:11 AM
GNU ToolChain for ARM, Linux 2.6.14-2/binutil-2.16/gcc 4.0.2/glibc-2.3.5 kumar_bst Linux - Software 0 01-22-2008 05:59 AM
ARM Toolchain Problem richardji Linux - General 2 08-08-2005 11:24 PM


All times are GMT -5. The time now is 03:23 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration