Next Previous Contents

3. distcc Compatibility

3.1 distcc with ccache

distcc works well with the ccache tool for caching compilation results. The best way to use the two of them together is to create a masquerade dir for ccache and a masquerade dir for distcc, and update your path to have the ccache-in-disguise links be found first, followed by the distcc-in-disguise links, and finally the real compiler. For instance:

PATH="/usr/lib/ccache/bin:/usr/lib/distcc/bin:$PATH"
export PATH

Another alternative is to munge CC and/or CXX to mention both commands:

CC='ccache distcc'
CXX='ccache distcc g++'

3.2 distcc with autoconf

distcc works quite well with autoconf.

DISTCC_VERBOSE can give autoconf trouble because autoconf tries to parse error messages from the compiler. If you redirect distcc's diagnostics using DISTCC_LOG then it seems to be fine.

Some autoconf-based systems "freeze" the compiler name used for configure into their Makefiles. To make them use distcc, you should either set the PATH to include the distcc masquerade dir or set $CC prior to running ./configure, and/or override $CC on the right-hand-side of the Make command line.

Some poorly-written shell scripts may assume that $CC is a single word. Using a masquerade dir avoids this problem.

3.3 distcc with libtool

Some versions of libtool seem not to cope well when CC is set to more than one word, such as "distcc gcc". Setting CC=distcc, which is supported in 0.10 and later, seems to work well. Using a masquerade dir, which was first supported in 2.0, is even better (since it avoids problems with C++ programs too).

3.4 distcc with Gentoo Linux

Gentoo is a "ports"-based free software distribution, in which packages are always built from source on installation. distcc works well with Gentoo to speed installation.

You can install distcc either using the upstream tarball from distcc.samba.org (which may be newer), or using emerge distcc to get the Gentoo port, which may be better integrated. You can also get ccache with emerge ccache.

Using distcc (and ccache) to speed your "emerge" commands is simplicity itself since full support for these packages is already built into portage. The two items you need to customize for your system are the MAKEOPTS value and the DISTCC_HOSTS value. You can either set these in the /etc/make.conf file, or you can export them from your local environment. Then, simply /etc/make.conf to add the "distcc" (and "ccache") features to the "FEATURE" setting (uncommenting the line, if needed), start up any missing remote distccd servers, and portage will take care of munging the PATH that the ebuild uses in an appropriate manner (note that the Gentoo version of distcc comes with a masquerade dir as a part of the standard installation, and has had this since distcc-1.1-r8 (when it was first patched into the ebuild). For example, if you wanted 9 parallel compiles and you had 4 remote systems, you might run something like this:

export MAKEOPTS=-j9
export DISTCC_HOSTS='local larry moe curly shemp'
emerge 
packagename

To use distcc for compilations outside of an emerge/ebuild command, include the /usr/lib/distcc/bin dir early on your PATH before configuring/compiling the package.

3.5 distcc with gcc dependency computation

gcc has the ability to produce information about header dependencies as a side-effect of preprocessing. These can be included in Makefiles in various ways to make sure that files are up-to-date.

This feature is enabled using -MD, -M and related options.

Unfortunately, gcc changed the behaviour of this feature between gcc 2.95 and 3.x in such a way that it seems properly for distcc to generally support it. The difficulty is that the filename to which dependencies are written depends in a very complicated way on the gcc command line. distcc needs to change the command line to run the preprocessor locally and the compiler remotely, and this can sometimes cause problems. (This also causes problems for Makefiles that are supposed to work with both versions of the compiler.)

-M causes gcc to produce dependency information instead of compiling. distcc understands this and passes the option straight through to gcc. It should work correctly.

With gcc 2.95, -MD always writes dependencies into the preprocessor's working directory. distcc should work fine.

With gcc 3.2, -MD writes the output into either the source directory or output directory, depending on the presence of the -o option. However, gcc 3.2 also has a -MF option that can be used to explicitly set the dependency output file, and this works well with distcc.

In summary: for gcc 2.95, no changes are required. For gcc 3.2, -MF should be used to specify the file to write dependencies to.


Next Previous Contents