Next
Previous
Contents
If you think you have found a bug, please check the manual
and the HACKING
file to see if it is a known
restriction. If not, please send a clear and detailed
report to Martin Pool mbp@samba.org
. (For a clear
and detailed description of "clear and detailed", see Simon
Tatham's advice on reporting bugs,
http://www.chiark.greenend.org.uk/~sgtatham/bugs.html.)
There are no known cases where distcc will produce incorrect
code, but they may exist. There are some restrictions on
distcc, and some possible optimizations that are not yet
implemented.
- Server-side errors are not directly visible to the
client. (The user needs to look at the server's log
file.) The server's error messages should be passed
back to the client.
- distcc waits for too long on unreachable hosts.
- There is no way to specify a non-default TCP port.
- Attackers can cause arbitrary damage if they can connect
to the volunteer's port, or impersonate a volunteer.
distcc should therefore only be used on trusted
networks. Running over
ssh
or some other
security mechanism might be possible, but would be slow.
- 4200 is not a registered port; I just picked it out of
my hat. If distcc proves popular, it ought to get a
proper IANA-allocated port.
- distcc probably has portability bugs on systems other
than GNU/Linux, but they should be accidental, not
fundamental.
- distcc ought to work with compilers other than GNU cc,
but it has not been tested.
- If a Makefile contains race conditions that make it
unsafe for parallel execution then distcc will lose in
the same way as a local compiler. Limitations of the
Make language mark it hard to write some parallel rules
correctly.
- If the Makefile hardcodes the name of the compiler
rather than using
$(CC)
then it may have to be
updated to work properly. ccache handles these
situations by allowing itself to be installed in place
of gcc
. It examines the name under which it
was invoked and decides to run another compiler. It may
be possible for distcc
to piggy-back on that.
- distcc could easily handle C++ programs, but it does not
yet recognize their file extensions.
- There are probably some valid compiler command lines
that distcc will fail to understand, and which will
therefore be run locally rather than distributed.
cc
argument parsing is complex and not
completely standardized.
- distcc (by design) can't handle compilers that need to
read other files from the local filesystem. This might
be a problem with such things as profile-directed
optimizers.
- distcc's protocol and file IO would probably have
trouble with source or object files over 2GB in size.
I've never heard of a file that large, and I rather
suspect gcc would not handle them well either.
Next
Previous
Contents