What's the difference between arm-linux- / arm-none-linux-gnueabi- / arm-fsl-linux-gnueabi- in LTIB?

cancel
Showing results for 
Search instead for 
Did you mean: 

What's the difference between arm-linux- / arm-none-linux-gnueabi- / arm-fsl-linux-gnueabi- in LTIB?

Jump to solution
25,914 Views
EdSutter
Senior Contributor II

Showing off my stupidity yet again I suppose...

I'm on a SABRESD board with linux running (LTIB).  I wanted to write a simple "hello-world.c"

to make sure I used the correct tools.  So I built it with arm-fsl-linux-gnueabi-gcc (under /opt/freescale), moved it

to my embedded system and it worked as expected.  To further test, I built it again using arm-none-linux-gnueabi-gcc

figuring that it would not run, but it worked.

Then I did a quick ls -l on the bin directory and I see that two different named toolsets all linked to arm-fsl-linux-gnueabi-xxx

under /opt/freescale; giving a total of three different named gcc toolsets all pointing to the same executable.

What's up with that?  The bare-metal tools have to use different libs than the linux-user-space tools right?

Is this done internally based on argv[0] or something?

Ed

Labels (1)
1 Solution
3,824 Views
Raybiztech
Contributor V

yes, what you said is right. If you cross compile your application using these three compilers

* arm-fsl-linux-gnueabi-gcc

* arm-linux-gcc

* arm-none-linux-gnueabi-gcc

having three different executable names, and if you check elf formats of the executables (readelf -a <executable name ) all sections are similar.

And you can find the linkages to arm-fsl-linux-gnueabi-XXX, the reason behind this may be like this, as we are compiling different packages provided by different vendors using LTIB, by default the tool chains provided by those package vendors may point to arm-linux-XXX or arm-none-linux-gnueabi-XXX. But the LTIB for IMX6, we are using is provided by freescale, so every package installed using LTIB will be cross compiled using freescale toolchain. Hence, tool chains like arm-linux-XXX or arm-none-linux-gnueabi-XXX used by different packages are linked to arm-fsl-linux-gnueabi-xxx.

Thanks & Regards,

Sasidhar.

View solution in original post

5 Replies
3,824 Views
syedmuqthyar
Contributor II

Simple Answer, all arm-linux-* and arm-none-linux-gnueabi-* are symbolic links and are pointed to arm-fsl-linux-gnueabi-*

which ever tool name you use, it will use only arm-fsl-linux-gnueabi-*

Example:


$ ls -l /opt/freescale/usr/local/gcc-4.4.4-glibc-2.11.1-multilib-1.0/arm-fsl-linux-gnueabi/bin/arm-*linux*gcc

-r-xr-xr-x 2 root root 231900 2010-09-20 17:06 /opt/freescale/usr/local/gcc-4.4.4-glibc-2.11.1-multilib-1.0/arm-fsl-linux-gnueabi/bin/arm-fsl-linux-gnueabi-gcc

lrwxrwxrwx 1 root root    25 2013-03-18 00:23 /opt/freescale/usr/local/gcc-4.4.4-glibc-2.11.1-multilib-1.0/arm-fsl-linux-gnueabi/bin/arm-linux-gcc -> arm-fsl-linux-gnueabi-gcc

lrwxrwxrwx 1 root root    25 2013-03-18 00:23 /opt/freescale/usr/local/gcc-4.4.4-glibc-2.11.1-multilib-1.0/arm-fsl-linux-gnueabi/bin/arm-none-linux-gnueabi-gcc -> arm-fsl-linux-gnueabi-gcc

0 Kudos
3,824 Views
Raybiztech
Contributor V

GCC is a popular tool chain that can generate executables for wide range of architectures including x86, ARM v4/v5/v6/v7, and many others. In personal computers GNU GCC is a compiler that compiles an application written for LINUX X86 PC. When the host and target architectures are different, the tool chain is called " cross compiler ".

You may come across different tool chains to cross compile your application for ARM like arm-none-linux-gnueabi, arm-none-eabi, arm-eabi, arm-fsl-linux-gnueabi-gcc etc.

Tool chains have  a loose name convention like arch [-vendor] [-os] - eabi

arch -      refers to target architecture (which in our case is ARM)

vendor -  refers to toolchain supplier

os -         refers to the target operating system

eabi -      refers to Embedded Application Binary Interface

some illustrations as follows :

arm-none-eabi - This tool chain targets for ARM architecture, has no vendor, does not target an operating system and complies with the ARM EABI.

arm-none-linux-gnueabi - This toolchain targets the ARM architecture, has no vendor, creates binaries that run on the Linux operating system, and uses the GNU EABI. It is used to target ARM-based Linux systems.

So, If you built your application "helloworld.c" with arm-none-linux-gnueabi-gcc (or) arm-fsl-linux-gnueabi-gcc, executable will work on your ARM target board as the tool chain has only difference in vendor.

Thanks & Regards,

Sasidhar

3,824 Views
EdSutter
Senior Contributor II

Thanks for the description of the naming convention.  I've also seen 'coff' and 'elf' (file format) built into the name at times.

Still, my question stands... under /opt/freescale/.../bin there are three sets of executables; for example take xx-gcc...

    * arm-fsl-linux-gnueabi-gcc

    * arm-linux-gcc

    * arm-none-linux-gnueabi-gcc

What's the point of having these linkages unless the underlying executable does something different

based on argv[0]?

0 Kudos
3,825 Views
Raybiztech
Contributor V

yes, what you said is right. If you cross compile your application using these three compilers

* arm-fsl-linux-gnueabi-gcc

* arm-linux-gcc

* arm-none-linux-gnueabi-gcc

having three different executable names, and if you check elf formats of the executables (readelf -a <executable name ) all sections are similar.

And you can find the linkages to arm-fsl-linux-gnueabi-XXX, the reason behind this may be like this, as we are compiling different packages provided by different vendors using LTIB, by default the tool chains provided by those package vendors may point to arm-linux-XXX or arm-none-linux-gnueabi-XXX. But the LTIB for IMX6, we are using is provided by freescale, so every package installed using LTIB will be cross compiled using freescale toolchain. Hence, tool chains like arm-linux-XXX or arm-none-linux-gnueabi-XXX used by different packages are linked to arm-fsl-linux-gnueabi-xxx.

Thanks & Regards,

Sasidhar.

3,824 Views
EdSutter
Senior Contributor II

Ok, I guess that makes sense.

Thanks,

0 Kudos