Distcc/Cross-Compiling/zh-cn

本文向你展示如何配置distcc在不同的处理器架构之间进行交叉编译.

介绍
is a tool that lets you share the burden of software compiling across several networked computers. As long as the networked boxes are all using the same toolchain built for the same processor architecture, no special setup is required.

This guide provides instructions on how to configure distcc to compile for different architectures.

安装必要的工具
First, you will need to emerge on all the machines that will be involved in the compiling process. is a tool that makes building cross-architecture toolchains easy. Its usage is straightforward: will build a full cross-toolchain targeting the Sparc architecture. This includes binutils, gcc, glibc, and linux-headers.

You will need to emerge the proper cross-toolchain on all the helper boxes. If you need more help, try running.

如果你想对交叉工具链进行微调，这里有个脚本可以在命令行中输出要在帮助编译的机器上安装的交叉开发包的的确切版本（这个脚本需要在目标机器上运行）.

Next, you will need to emerge on all the machines that will be involved in the process. This includes the box that will run emerge and the boxes with the cross-compilers. Please see the Gentoo Distcc Documentation for more information on setting up and using.

Intel x86 subarchitectures
If you are cross-compiling between different subarchitectures for Intel (e.g. i586 and i686), you must still build a full cross-toolchain for the desired CHOST, or else the compilation will fail. This is because i586 and i686 are actually different CHOSTs, despite the fact that they are both considered "x86." Please keep this in mind when you build your cross-toolchains. For example, if the target box is i586, this means that you must build i586 cross-toolchains on your i686 helper boxes.

SPARC
Using might fail with one of the following errors:

如果发生上述错误，尝试使用下面的命令：

配置distcc以便正确的交叉编译
In the default distcc setup, cross-compiling will not work properly. The problem is that many builds just call instead of the full compiler name (e.g. ). When this compile gets distributed to a distcc helper box, the native compiler gets called instead of your shiny new cross-compiler.

Fortunately, there is a workaround for this little problem. All it takes is a wrapper script and a few symlinks on the box that will be running. We'll use a Sparc box as an example. Wherever you see  below, you will want to insert your own CHOST value (  for an AMD64 box, for example). When you first emerge distcc, the directory looks like this:

这里你需要做：

Next, we'll create the new script on this box. Fire up your favorite editor and create a file with the following text in it, then save it as. Remember to change the CHOST value (in this case, ) to the actual CHOST of the box that will be running the emerge.

接下来，将此脚本设置为可执行，并创建适当的符号链接：

当你完成以后，看起来像这样：

然后我们要确保这些封装脚本在升级distcc包之后不会被替换成之前的符号链接. 我们可以提通过在中添加下面的 代码来实现：

Then create this file:

Give it the proper permissions:

恭喜，你已经有一个可以工作的交叉编译的配置了（希望如此）.

这是如何工作的
When is called, it checks to see what it was called as (e.g. ,  , etc.) When distcc then distributes the compile to a helper box, it passes along the name it was called as. The distcc daemon on the other helper box then looks for a binary with that same name. If it sees just, it will look for , which is likely to be the native compiler on the helper box, if it is not the same architecture as the box running. When the full name of the compiler is sent (e.g. ), there is no confusion.

故障排除
This section covers a number of common problems when using for cross-compiling.

远程主机 distccd 编译错误
When receiving the message  within a remote host's  file, see the above notes concerning specifying the correct architecture name (ie. ).

Another solution is to uninstall and re-install compiler tools, using the  option, or ensuring  no longer exists, and then completely reinstall the cross compiler.

It might also be wise to edit the remote host's, and ensure the contents of the CFLAGS variable are similar on all computers or hosts performing compiler operations.

Failed to exec $TARGET-unknown-linux-gnu-gcc: No such file or directory
封装脚本也许无法执行，即使有正确的权限：

要解决这一问题，请确保创建的封装脚本包含目标架构的全名：