There are two approaches I've used for ARM/Linux tools. The easiest is to download a pre-built tool chain directly. Pro: It just works and you can get on with the interesting part of your project Con: You are stuck with whichever version of gcc/binutils/libc they picked
If the later matters to you, check out crosstool-ng. This project is a configuration tool similar to the Linux kernel configuration application. Set which versions of gcc, binutils, libc (GNU or uCLibc), threading, and Linux kernel to build and crosstool-ng does the rest (i.e. downloads the tar balls, configures the tools, and builds them). Pro: You get exactly what you selected during the configuration Con: You get exactly what you selected during the configuration
meaning you take on full responsibility for the choice of compiler/binutil/libc and their associated features/shortcomings/bugs. Also, as mentioned in the comments, there is some "pain" involved in selecting the versions of binutils, C library etc. as not all combinations necessarily work together or even build.
One hybrid approach might be to start with the pre-built tools and replace them later with a custom solution via crosstool-ng if necessary.
Update: The answer originally used the CodeSourcery tools as an example of a pre-built tool chain. The CodeSourcery tools for ARM were free to download from Mentor Graphics, but they are now called the Sourcery CodeBench and must be purchased from Mentor Graphics. Other options now include Linaro as well as distribution specific tools from Android, Ubuntu, and others.
I use the emdebian toolchain for compiling stuff for my ARM machines that isn't happy being compiled natively in the small resources available (/me glares at the kernel). The main package is gcc-4.X-arm-linux-gnueabi (X = 1,2,3), and provides appropriately suffixed gcc/cpp/ld/etc commands. I add this to my sources.list:
deb http://www.emdebian.org/debian/ unstable main
Of course, if you're not using Debian, this probably isn't so useful, but by gum it works well for me.
I've used scratchbox while experimenting with building apps for maemo (Nokia N810), which uses an ARM processor. Supposedly, scratchbox is not restricted to maemo development.
I've used crosstool on several targets. It's great as long as you want to build your toolchain from scratch. Of course there are several pre built toolchains for arm as well, just google it -- too many to mention here.
1) In my opinion building your own toolchain works the best. You end up having tight control over everything, plus if you're new to embedded linux, it's a GREAT learning experience.
2) Don't go with a commercial toolchain. Even if you don't want to take the time to build your own, there are free alternatives out there.
If your company will spend the money, have them buy you a jtag debugger. It will save you tons of time. and it allows you to easily learn and step through the kernel startup, etc.. I highly recommend using the Lauterbach jtag products... They work with a ton of targets and the software is cross platform. Their support is great as well.
If you can't get a jtag debugger and you're working in the kernel, use an VM to do that, usermode linux, vmware..etc.. your code will be debugged on x86.. porting it to your arm target will be a different story, but it's a cheaper way to iron out some bugs.
If you're porting a bootloader, use uboot. Of course, if you're using a reference platform, then you're probably better off using what they provide with the BSP.
Buildroot is a tool I've had reasonably good luck with for building a custom uClibc-based toolchain from scratch. It's very customizable, and not excessively particular about what distribution you happen to be running on.
Also, many of its existing users (ie. embedded router distros) are also targeting ARM.
where ARCH is arm or armeb, VENDOR is unknown or softfloat, OS is linux, and LIBC is gnu or uclibc.
If all you want is a compiler (and linker) for the kernel, the LIBC part is irrelevant, and you can use -s1/--stage1 to inform crossdev that you only need binutils and gcc.
This is what Eurotech uses for their Debian ARM distibution. You'll note that they don't recommend using a cross compiler if you can avoid it. Compiling on the target itself tends to be a more reliable way of getting outputs that you know will run.
发布评论
评论（7）
我对 ARM/Linux 工具使用了两种方法。 最简单的是直接下载预构建的工具链。
优点：它确实有效，您可以继续项目中有趣的部分
缺点：您只能使用他们选择的 gcc/binutils/libc 版本。
如果后者对您很重要，请查看 crosstool-ng。 该项目是一个类似于Linux内核配置应用程序的配置工具。 设置要构建的 gcc、binutils、libc（GNU 或 uCLibc）、线程和 Linux 内核的版本，crosstool-ng 完成其余的工作（即下载 tar 球、配置工具并构建它们）。
专业版：您得到的正是您在配置过程中选择的内容
缺点：您得到的正是您在配置过程中选择的内容，
这意味着您对编译器/binutil/libc 的选择及其相关功能/缺点/错误承担全部责任。 另外，正如评论中提到的，选择 binutils、C 库等的版本会带来一些“痛苦”，因为并非所有组合都必须一起工作甚至构建。
一种混合方法可能是从预构建的工具开始，然后在必要时通过 crosstool-ng 用自定义解决方案替换它们。
更新：答案最初使用 CodeSourcery 工具 作为示例预构建的工具链。 适用于 ARM 的 CodeSourcery 工具可免费下载来自 Mentor Graphics，但它们现在称为 Sourcery CodeBench，必须从 Mentor Graphics 购买。 其他选项现在包括 Linaro 以及来自 Android、Ubuntu 等的特定于发行版的工具。
There are two approaches I've used for ARM/Linux tools. The easiest is to download a pre-built tool chain directly.
Pro: It just works and you can get on with the interesting part of your project
Con: You are stuck with whichever version of gcc/binutils/libc they picked
If the later matters to you, check out crosstool-ng. This project is a configuration tool similar to the Linux kernel configuration application. Set which versions of gcc, binutils, libc (GNU or uCLibc), threading, and Linux kernel to build and crosstool-ng does the rest (i.e. downloads the tar balls, configures the tools, and builds them).
Pro: You get exactly what you selected during the configuration
Con: You get exactly what you selected during the configuration
meaning you take on full responsibility for the choice of compiler/binutil/libc and their associated features/shortcomings/bugs. Also, as mentioned in the comments, there is some "pain" involved in selecting the versions of binutils, C library etc. as not all combinations necessarily work together or even build.
One hybrid approach might be to start with the pre-built tools and replace them later with a custom solution via crosstool-ng if necessary.
Update: The answer originally used the CodeSourcery tools as an example of a pre-built tool chain. The CodeSourcery tools for ARM were free to download from Mentor Graphics, but they are now called the Sourcery CodeBench and must be purchased from Mentor Graphics. Other options now include Linaro as well as distribution specific tools from Android, Ubuntu, and others.
我使用 emdebian 工具链为我的 ARM 机器编译东西，但不喜欢在可用的小资源中进行本机编译（/me 盯着内核）。 主包是 gcc-4.X-arm-linux-gnueabi (X = 1,2,3)，并提供适当后缀的 gcc/cpp/ld/etc 命令。 我将其添加到我的
sources.list中：当然，如果您不使用 Debian，这可能不是那么有用，但是 gum 它对我来说效果很好。
I use the emdebian toolchain for compiling stuff for my ARM machines that isn't happy being compiled natively in the small resources available (/me glares at the kernel). The main package is
gcc-4.X-arm-linux-gnueabi(X = 1,2,3), and provides appropriately suffixed gcc/cpp/ld/etc commands. I add this to mysources.list:Of course, if you're not using Debian, this probably isn't so useful, but by gum it works well for me.
我在尝试为使用 ARM 处理器的 maemo (Nokia N810) 构建应用程序时使用了 scratchbox。 据说，scratchbox 并不局限于 maemo 开发。
I've used scratchbox while experimenting with building apps for maemo (Nokia N810), which uses an ARM processor. Supposedly, scratchbox is not restricted to maemo development.
我已经在几个目标上使用了 crosstool。 只要您想从头开始构建工具链，它就很棒。
当然，也有几个针对 ARM 的预构建工具链，只需 google 一下即可 - 太多了，这里就不一一列举了。
1）我认为构建自己的工具链效果最好。 您最终可以严格控制一切，而且如果您是嵌入式 Linux 新手，这将是一次很棒的学习体验。
2）不要使用商业工具链。 即使您不想花时间构建自己的，也有免费的替代方案。
如果你的公司愿意花钱，让他们给你买一个 jtag 调试器。
它将为您节省大量时间。并且它可以让您轻松学习并逐步完成内核启动等。
我强烈建议使用 Lauterbach jtag 产品...它们适用于大量目标，并且该软件是跨平台的。 他们的支持也很大。
如果您无法获得 jtag 调试器并且您正在内核中工作，请使用 VM 来执行此操作，用户模式 linux、vmware 等...您的代码将在 x86 上进行调试...将其移植到您的 arm 目标将这是一个不同的故事，但这是解决一些错误的更便宜的方法。
如果您要移植引导加载程序，请使用 uboot。 当然，如果您使用的是参考平台，那么您最好使用他们随 BSP 提供的平台。
我希望这有帮助。
I've used crosstool on several targets. It's great as long as you want to build your toolchain from scratch.
Of course there are several pre built toolchains for arm as well, just google it -- too many to mention here.
1) In my opinion building your own toolchain works the best. You end up having tight control over everything, plus if you're new to embedded linux, it's a GREAT learning experience.
2) Don't go with a commercial toolchain. Even if you don't want to take the time to build your own, there are free alternatives out there.
If your company will spend the money, have them buy you a jtag debugger.
It will save you tons of time. and it allows you to easily learn and step through the kernel startup, etc..
I highly recommend using the Lauterbach jtag products... They work with a ton of targets and the software is cross platform. Their support is great as well.
If you can't get a jtag debugger and you're working in the kernel, use an VM to do that, usermode linux, vmware..etc.. your code will be debugged on x86.. porting it to your arm target will be a different story, but it's a cheaper way to iron out some bugs.
If you're porting a bootloader, use uboot. Of course, if you're using a reference platform, then you're probably better off using what they provide with the BSP.
I hope that helps.
Buildroot 是一个工具，我很幸运地从头开始构建了一个基于 uClibc 的自定义工具链。 它是非常可定制的，并且不会过多地关注您碰巧运行的发行版。
此外，它的许多现有用户（即嵌入式路由器发行版）也瞄准了 ARM。
Buildroot is a tool I've had reasonably good luck with for building a custom uClibc-based toolchain from scratch. It's very customizable, and not excessively particular about what distribution you happen to be running on.
Also, many of its existing users (ie. embedded router distros) are also targeting ARM.
如果您使用 Gentoo，获取交叉编译工具链就像
ARCH为arm或armeb、VENDOR 为一样简单未知或softfloat，OS是linux，LIBC是gnu> 或uclibc。如果您想要的只是内核的编译器（和链接器），则
LIBC部分无关紧要，您可以使用-s1/--stage1 通知 crossdev 您只需要 binutils 和 gcc。If you're using Gentoo, getting a cross-compiling toolchain is as easy as
where
ARCHisarmorarmeb, VENDOR isunknownorsoftfloat,OSislinux, andLIBCisgnuoruclibc.If all you want is a compiler (and linker) for the kernel, the
LIBCpart is irrelevant, and you can use-s1/--stage1to informcrossdevthat you only needbinutilsandgcc.这就是 Eurotech 在其 Debian ARM 发行版中使用的内容。 您会注意到，如果可以避免的话，他们不建议使用交叉编译器。 在目标本身上进行编译往往是获得您知道将运行的输出的更可靠方法。
This is what Eurotech uses for their Debian ARM distibution. You'll note that they don't recommend using a cross compiler if you can avoid it. Compiling on the target itself tends to be a more reliable way of getting outputs that you know will run.