arm-linux-gcc 与 arm-elf-gcc
我正在研究 uClinux 系统，该系统使用arm-linux-xxx构建内核，但使用arm-elf-xxx构建用户应用程序。
如果应用程序打算在 Linux 上运行，那么使用 arm-linux-xxx 构建所有内容不是更好吗？
在整个 uClinux 构建配置中的哪里设置该选项？
I am looking at uClinux system that builds the kernel with arm-linux-xxx, but builds the user apps with arm-elf-xxx.
If the apps are intended to run on linux, wouldn't it be better to build everything with arm-linux-xxx ?
Where does one set that option in the overall uClinux build config?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
编译器的名称不一定意味着什么。 根据编译器的构建者（并为其命名），您将得到不同的结果。 可以说，特定配置有一个正确的名称，但某些随机编译的 gcc 可能不正确。
对于 CodeSourcery 编译器（可能是最正确的名称），请参阅其平台页面了解具体内容他们的命名方式。
The names of the compilers don't necessarily mean anything. Depending on who built the compilers (and named them), you'll get differing results. Arguably, there is a correct name for a particular configuration, but some random compiled gcc may not be correct.
For the CodeSourcery compilers (likely the most correct names), see their platforms page for what their naming means.
您可以运行
arm-linux-gcc -v和arm-elf-gcc -v来查看这两个版本的 gcc 之间的一些差异（例如目标架构/语言） 。You can run
arm-linux-gcc -vandarm-elf-gcc -vto see some differences between these two versions of gcc (such as target architectures/languages).ELF 是Linux 和许多其他使用的二进制格式：
ELF is the binary format linux and many others use:
我似乎记得在某个时候，中间的那一点并不重要。 正如已经提到的，elf 是标准文件格式，您无论如何都想使用它，并且无论如何都会得到它，而与二进制名称无关。 可能（或不）更重要的是调用约定，我不知道在调用共享库函数时是否必须使调用约定匹配，或者是否在其他地方为您处理。
I seem to remember at some point that that bit in the middle didnt matter. As already mentioned elf is the standard file format, you want to use that anyway and will get that anyway independent of the binary name. What may (or not) matter more is the calling convention, I dont know if when calling a shared library function you have to get your calling convention to match or if it is handled for you somewhere else.
区别在于，arm-elf-xxx 工具链的链接输出是 Linux 可加载二进制文件，而 arm-linux-xxx 输出内核对象 (ko)，它是具有自己的链接格式（对于模块）的 blob，或者主内核本身，不需要打包格式。 即，对于用户空间，您希望最终的动态链接对象是 ELF 可执行文件、库或共享对象。 对于内核空间，您希望最终对象（内核或模块）采用 linux-arm-kernel 链接格式。
您会注意到两个目标的中间对象（.o 文件）可能都是 ELF，因为这是工具链所期望的。
The difference is that the linked output from the arm-elf-xxx toolchain is a linux loadable binary, while arm-linux-xxx outputs a kernel object (ko), which is a blob with its own linkage format (for modules), or the main kernel itself, which doesn't need a packaging format. I.e., for user space you want the final dynamically linked object to be an ELF executable, library, or shared object. For kernel space, you want the final object (kernel or module) to be in the linux-arm-kernel linkage format.
You'll notice that the intermediate objects (.o files) of both targets are probably all ELF, since that is what the toolchain is expecting.
在我们的例子中，我们使用 sparc-elf-gcc 构建 Linux，并使用 sparc-..-linux-gcc 构建 busybox（在 Linux 上运行的应用程序）。 我认为这是正确的，而不是相反。
In our case we build linux using sparc-elf-gcc and we build busybox(appliation run on linux) using sparc-..-linux-gcc. and I think this is correct, not the other way around.