Distcc/Cross-Compiling/en

This guide shows you how to set up distcc for cross-compiling across different processor architectures.

Introduction
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 will show you how to configure  to compile for different architectures.

Emerge the needed utilities
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 targetting 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.

If you want to fine tune the cross-toolchain, here is a script that will produce a command line with the exact versions of the cross development packages to be built on the helper boxes (the script is to be run on the target box).

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 x86 (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:

If this happens, try using the following command instead:

Configuring distcc to cross-compile correctly
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 (  for an AMD64 box, for example). When you first emerge distcc, the directory looks like this:

Here is what you want to do:

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 (in this case, ) to the actual CHOST of the box that will be running the emerge.

Next, we'll make the script executable and create the proper symlinks:

When you're done, will look like this:

Next we want to make sure that these wrappers stay available after upgrading the distcc package as it will overwrite the symbolic links. We can do this through a file that looks like so:

Congratulations; you (hopefully) now have a working cross-distcc setup.

How this works
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.

Troubleshooting
This section covers a number of common problems when using distcc for cross-compiling.

Remote host distccd COMPILE ERRORS
When receiving the message  within a remote host's  file, see the above notes concerning specifying the correct architecture name (ie. crossdev -t $TARGET).

Another solution is to uninstall and re-install crossdev compiler tools, using the crossdev --clean 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  variable are similar on all computers or hosts performing compiler operations.

Failed to exec $TARGET-uknown-linux-gnu-gcc: No such file or directory
The wrapper scripts might fail to execute, even with correct permissions:

To resolve this, make sure to have the wrapper script created with the complete name of the architecture target: