‘壹’ arm-linux-gcc 和 arm-elf-gcc 的区别
在基于ARM的嵌入式系统开发中，常常用到交叉编译的GCC工具链有两种：
arm-linux-*和 arm-elf-*，两者区别主要在于使用不同的C库文件。arm-linux-*使用
GNU的Glibc，而arm-elf-*一般使用 uClibc/uC-libc或者使用REDHAT专门为嵌入式系统
的开发的C库newlib.Glibc。uClibc/uC-libc以及 newlib都是C语言库文件，只是所应
用的领域不同而已，Glibc是针对PC开发的，uClibc/uC-libc是与Glibc API兼容的小型
化C语言库，实现了Glibc部分功能。
关于uClibc/uC-libc的说明，详见如下：
There are two libc libraries commonly used with uClinux. uC-libc and
uClibc. They are quite different despite their similar names. Here is a
quick overview of how they are different.
uC-libc is the original library for uClinux. It was based on sources
from the Linux-8086 C library which was part of the ELKs project with m68000
support added by Jeff Dionne and Kenneth Albanowski. It is a fairly complete
libc implementation, however, some of the API's are a little non-standard
and quite a few common libc routines are not present. Currently it has
stable support for m68000, ColdFire and ARM (Non-MMU) architectures. It was
primary design goal is to be small and light weight. It does try to conform
to any standards, although its API tries to be compatible with most libcs,
it is not always exactly the same.
The uClinux distribution provides an environment that can compile using
either uC-libc or uClibc depending on your needs. For m68000 and Coldfire
platforms it is generally better to chose uC-libc as it supports shared
libraries and is the most commonly used libc for these CPUs. uClibc also
works quite well with almost all platforms supported by the distribution.
Which libc you choose to use will be decided by your requirements
uClinux有两个经常使用的libc库：uC-libc和uClibc。虽然两者名字很相似，其实有差
别，下面就简单的介绍一下二者的不同之处。uC -libc是最早为uClinux开发的库，是
Jeff Dionne和Kenneth Albanowski为在EKLs项目中支持m68000在Linux-8086 C库源码
上移植的。uC-libc是一个完全的libc实现，但其中有一些api是非标准的，有些libc的
标准也没有实现。uC-libc稳定地支持 m68000，ColdFire和没有MMU的ARM。其主要设计
目标是“小”、"轻"，并尽量与标准一致，虽然它的API和很多libc兼容，但是似乎并
不像它期望的那样和所有标准一致。
uClibc就是为了解决这个问题从uC-libc中发展出来的。它的所有API都是标准的(正确
的返回类型，参数等等)，它弥补了uC-libc中没有实现的libc标准，现在已经被移植到
多种架构中。一般来讲，它尽量兼容glibc以便使应用程序用uClibc改写变的容易。
uClibc能够在标准的 VM linux和uClinux上面使用。为了应用程序的简洁，它甚至可以
在许多支持MMU的平台上被编译成共享库。Erik Anderson在uClibc背后做了很多的工
作。uClibc支持许多系列的处理器：m68000，Coldfire，ARM，MIPS，v850， x86，
i960，Sparc，SuperH，Alpha，PowerPC和Hitachi 8。不断增加的平台支持显示uClibc
能够很容易的适应新的架构。uClinux发行版提供了环境能够让你选择使用uC-libc或是
uClibc编译。对于m68000和Coldfire平台来说，选择uC-libc还是稍微好一点，因为它
支持共享库，而共享库是这些cpu经常使用的 libc.uClibc也几乎和所有的平台都能很
好的工作。选择哪种libc取决于你的需求。
newlib 是一个用于嵌入式系统的开放源代码的C语言程序库，由libc和libm两个库组
成，特点是轻量级，速度快，可移植到很多CPU结构上。newlib实现了许多复杂的功
能，包括字符串支持，浮点运算，内存分配(如malloc)和I/O流函数(printf，fprinf()
等等)。其中libc提供了c 语言库的实现，而libm提供了浮点运算支持。
在为ARM交叉编译gcc编译器时，对gcc指定不同的配置选项时，使用的C语言库就不同，
gcc编译器默认使用Glibc，也可以使用 uClibc/uC-libc(基本兼容Glibc API)，当使用
--with-newlib时，gcc编译器不使用Glibc。当没有交叉编译Glibc时，可以使用
--with-newlib禁止连接Glibc而编译bootstrap gcc编译器。从gcc源目录下的
config/arm中的t-linux和t-arm-elf中可以看出，不同的--target也影响gcc连接C语言
库，t-linux(--target=arm-linux)默认使用Glibc，-arm-elf(--target=arm-elf)使用
- Dinhibit_libc禁止连接Glibc，这时我们就可以使用newlib等其他C语言库编译GCC工
具链。
虽然GCC工具链配置了不同的的C语言库，但由于这些C语言库都可以用来支持GCC，它们
对核心数据的处理上不存在较大出入。因而arm-linux-* 和 arm-elf-*区别主要表现在
C语言库的实现上，例如不同系统调用，不同的函数集实现，不同的ABI\启动代码以及
不同系统特性等微小的差别。
arm-linux-*和 arm-elf-*的使用没有一个绝对的标准，排除不同库实现的差异，gcc可
以编译任何系统。arm-linux-*和 arm-elf-*都可以用来编译裸机程序和操作系统，只
是在遵循下面的描述时系统程序显得更加协调：
arm-linux-*针对运行linux的ARM机器，其依赖于指定的C语言库Glibc，因为同样使用
Glibc的linux而使得arm-linux-*在运行linux的ARM机器上编译显得更加和谐。
arm-elf-*则是一个独立的编译体系，不依赖于指定的C语言库Glibc，可以使用newlib
等其他C语言库，不要求操作系统支持，当其使用为嵌入式系统而设计的一些轻巧的C语
言库时编译裸机程序(没有linux等大型操作系统的程序)，如监控程序，bootloader等
能使得系统程序更加小巧快捷。
‘贰’ 如何使用GNU GCC编译MQX应用
1. 安装MQX4.0，在飞思卡尔官网把MQX的安装文件下载下来。
2. 安装好之后会在安装目录下生成如下图所示的子目录。
build目录：包含了飞思卡尔不同平台不同编译器的相关库的Makefile文件。具体内容如下列表示意图所示：
build
+---common
| +---make ... shared Makefiles with global settings, variables and paths
+--- ... board-specific folder
| +---make ... folder contains mass-build Makefile for all libraries
| +---tools ... tool-specific global settings, variables and paths
| +---bsp ... BSP Library Makefile
| +---psp ... PSP Library Makefile
| +---mfs ... MFS Library Makefile
| +---rtcs ... RTCS Library Makefile
| +---shell ... Shell Library Makefile
| +---usbd ... USB Device Library Makefile
| +---usbh ... USB Host Library Makefile
+---
+---make
3. 安装CodeWarrior Development Studio V10.5编译器。在飞思卡尔官网把CW10.5的安装文件下载下来。安装CW10.5时，请注意安装目录名称不要带空格。
CW10.5的Cross_Tools目录已经自带了GNU GCC for ARM Cortex-M4内核的交叉编译工具链。
4. 安装MinGW(Minimalist GNU on Windows) GNU工具集，在Windows下GNU GCC需要使用make.exe和sed.exe等工具。
5. 上述软件安装完毕后，按照实际安装情况，修改编译MQX所需的交叉工具链的目录。
1).修改全局宏定义脚本$MQX_DIR\build\common\make\global.mak
指定GNU 交叉工具链的安装路径TOOLCHAIN_ROOTDIR宏定义，如：
TOOLCHAIN_ROOTDIR = C:/Freescale/CW10_5
2).指定编译某一硬件平台需要GNU GCC编译器的具体安装路径。如需要编译twrk60d00m这款Demo板，修改脚本文件$MQX\build\twrk60d100m\make\tools\cw10gcc.mak，指定AS，CC，CX，AR，LD等工具的可执行文件。
#------------------------------------------------------------
# toolchain settings
#------------------------------------------------------------
AS = $(TOOLCHAIN_ROOTDIR)/Cross_Tools/arm-none-eabi-gcc-4_7_3/bin/arm-none-eabi-gcc.exe
CC = $(TOOLCHAIN_ROOTDIR)/Cross_Tools/arm-none-eabi-gcc-4_7_3/bin/arm-none-eabi-gcc.exe
CX = $(TOOLCHAIN_ROOTDIR)/Cross_Tools/arm-none-eabi-gcc-4_7_3/bin/arm-none-eabi-gcc.exe
AR = $(TOOLCHAIN_ROOTDIR)/Cross_Tools/arm-none-eabi-gcc-4_7_3/bin/arm-none-eabi-ar.exe
LD = $(TOOLCHAIN_ROOTDIR)/Cross_Tools/arm-none-eabi-gcc-4_7_3/bin/arm-none-eabi-gcc.exe
6. 修改完毕上述脚本后，就可以开始使用GNU GCC编译MQX。在windows命令窗口下进入需要编译的目录,如Tower K60的编译目录：$MQX\build\twrk60d100m\make。在命令行下输入make指令：
C:\Freescale\Freescale_MQX_4_0\build\twrk60d100m\make>mingw32-make build TOOL=cw10gcc CONFIG=debug
这条make指令能够将整个MQX进行编译，并生成bsp.a，psp.a，shell.a，rtcs.a，usbd.a，usbh.a等库文件。
7. MQX系统库编译完毕后，可以进行应用程序的编译。在命令窗口进入需要编译的应用程序目录。如需要编译hello例程代码，进入$MQX\mqx\examples\hello\make目录，在命令下输入make命令：
C:\Freescale\Freescale_MQX_4_0\mqx\examples\hello\make>mingw32-make BOARD=twrk60d100m TOOL=cw10gcc CONFIG=debug LOAD=intflash build
GNU GCC将会编译应用程序代码，并与MQX的bsp.a，psp.a的库文件链接，生成.elf格式的可以执行文件。
8. 下载调试.elf可执行文件。在CW10.5中New创建一个Bareboard Project工程，选择需要使用的下载调试器，并且选定使用GNU GCC作为编译器。在菜单Properties --> Run/Debug Setting中选择需要下载的目标文件。然后通过菜单Run-->Debug下载调试程序。
‘叁’ 用同一种语言（如c语言）编出来的软件格式为什么会有不同
我感觉你是在问，为什么各种软件要求的扩展名不同（也就是格式不同），比如word的doc，txt等等，是这样的么？
回答：
可能是无意中造成的，比如某人编了个软件，要求按照某种他自己定义的格式去读文件，而市面上没有这种格式，因此他就自己定义了一种，并用了一个特殊的扩展名。
也可能是有意这样做的，比如某公司编写了一软件a，这个软件很好，大家都用，其它公司看着眼红，也想编个软件b并且要能打开a软件的文件（也就是兼容a），a公司为了竞争需要，在下一版本的软件中特意改写了文件读取形式，让b软件打不开a文件。
因此，这跟编程语言不同没关系
回答第二个问题，安装完后产生的许多文件夹大部分是程序文件夹，也就是说这个软件的程序是放在那个文件夹下面的，整个文件夹就是那个软件，因此你看不懂，也不用看懂。这种文件夹不能删，删了的话软件就运行不了了。
‘肆’ 高版本gcc编译出的程序在低版本glibc机器上运行
比如我们用gcc 9.3.0编译程序，但需要发布的机器gcc版本是4.8.5，怎么办？
你可能想到如下方法
将libc和libstdc++静态编译，编译时带上如下参数。
glibc并不推荐静态链接，你依赖的其他库可能依赖的了glibc，并且往往是动态链接的，可以通过 nm <bin> | grep GLIBC_ 确定你的程序是否依赖了glibc。
使用携带gcc9.3.0环境的容器发布程序，是可以的。但是在一些没有容器且没有sudo权限的场合，依然不太友好。
这个方法虽然听起来不是很优雅，但其实如果你对elf文件有一些了解，是不错的方式。下面说下具体的方法。
当你有条件获得程序源码，并能够重新编译时，可以直接在编译时指定相关参数来解决。
先说编译时要增加的参数：
gcc参数
ld参数
这两个参数分别设置的elf文件中的rpath和interpreter字段。
rpath
全名 run-time search path ，是elf文件中一个字段，它指定了可执行文件执行时搜索so文件的第一优先位置，一般编译器默认将该字段设为空。elf文件中还有一个类似的字段runpath，其作用与rpath类似，但搜索优先级稍低。搜索优先级:
如果你需要使用相对路径指定lib文件夹，可以使用 ORIGIN 变量，ld会将ORIGIN理解成可执行文件所在的路径。
interpreter
动态库加载器，程序启动时，操作系统会先把控制权转交给ld-linux-x86-64.so.2，该so负责加载所有程序依赖的so。。这个字段在链接时会帮你自动设置，64bit程序一般为 /lib64/ld-linux-x86-64.so.2 。修改rpath或者LD_LIBRARY_PATH指向本地lib目录，但通过ldd程序，发现/lib64/ld-linux-x86-64.so.2这个so仍然指向系统so。原因就是这个字段是写死在elf文件中的，并不受LD_LIBRARY_PATH影响。
编译时带上这两个参数，下面只需要将你程序依赖的so打包一份，随程序进行发布即可。
当你无法编译程序时，也可以通过其他方式修改rpath和interpreter。这种情况需要使用到一个工具 patchelf ，通过 dnf install patchelf 即可安装。你可以通过它修改elf文件的rpath和interpreter：
除了绝对路径，一种比较常见的方式是在部署前，使用 pwd 获取当前路径，使用相对路径指向本地lib。
‘伍’ LINUX 的gcc等编程的工具如何启动我刚刚接触linux！！！
不需要专门的启动
偶也是初入门着
先在一个TXT文档里面编辑命令
保存为.c文件
点任务栏的。。启动命令行编辑器
进入你存放程序的地址
然后再编辑即可 gcc *.c -o
‘陆’ Linux下的gcc编译后生成Linux下的可执行文件，window下gcc编译后是exe文件，为什么不一样啊是怎么做到的
首先，这win和Linux下的gcc功能是一样的，实际的gcc.exe和linux下的gcc这两个文件不是一样的，他们毕竟需要在工作在不同的平台上，而且他们做的一些工作是有区别的。
编译过程是把源文件翻译成机器码，然后链接成一个整体，拼接成一个文件。不管是win下的exe还是Linux下的ELF，都是按照一定规范来的，比如头部放什么，尾部放什么，中间又存哪些信息等。但是，如果要编译出正确的可执行的文件，不同的操作系统里就必须按照不同的规范来组织这个文件。
这些文件的执行过程，并不是说它们可以直接执行，执行的时候，系统把它们从磁盘上，读到内存中，经过一系列的前期工作，才可以最终执行起来，这个前期过程都是操作系统来搞定的。
你不应该问gcc是怎么做到的，而应该问gcc为什么需要这样。如果你需要知道细节，去看《程序员的自我修养》
‘柒’ Uboot编译为什么没有生成elf格式的文件
1、通过gcc编译出来的是elf文件
2、通过objcpy可以把elf文件转换为bin文件
CC=ppc-gcc
LD=ppc-ld
OBJCOPY=ppc-obj
$(CC)-g$(CFLAG)-cboot.S
#先将boot.S文件生成boot.o
$(LD)-g-Bstatic-T$(LDFILE)
-Ttext0x12345600boot.o
--start-group-Mapboot.map-oboot.elf
#再将boot.o生成boot.elf
$(OBJCOPY)-Obinary-R.note-R.comment-Sboot.elfboot.bin
#接着将boot.elf转换为boot.bin
#使用-Obinary(或--out-target=binary)输出为原始的二进制文件
#使用-R.note(或--remove-section)输出文件中不要.note这个section，缩小了文件尺寸
#使用-S(或--strip-all)输出文件中不要重定位信息和符号信息，缩小了文件尺寸
‘捌’ 如何把.elf格式的文件编译成uimage格式
在终端中输入 gcc 文件名 -o 目标文件名 然后 ./目标文件名 就行了，没有目标文件名，自动存为 a 执行 ./a 就行了。 在使用Gcc编译器的时候，我们必须给出一系列必要的调用参数和文件名称。GCC编译器的调用参数大约有100多个，其中多数参数我们
‘玖’ elf是什么格式,怎么运行
Executable Linkable Format
就是可执行文件。
gcc 编出来的。
http://crquan.blogbus.com/logs/1651240.html