Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
distcc(1)		    General Commands Manual		     distcc(1)

       distcc -	distributed C/C++/ObjC compiler	with distcc-pump extensions

       distcc _compiler_ [COMPILER OPTIONS]

       distcc [COMPILER	OPTIONS]

       <compiler> [COMPILER OPTIONS]

       distcc [DISTCC OPTIONS]

       distcc  distributes  compilation	of C code across several machines on a
       network.	 distcc	should always generate the same	 results  as  a	 local
       compile,	 it  is	simple to install and use, and it is often much	faster
       than a local compile.

       This version incorporates plain distcc as well as an enhancement	called
       pump mode or distcc-pump.

       For  each  job,	distcc	in  plain mode sends the complete preprocessed
       source code and compiler	arguments across the network from  the	client
       to  a  compilation  server.  In pump mode, distcc sends the source code
       and recursively included	header files (excluding	those from the default
       system  header directories), so that both preprocessing and compilation
       can take	place on the compilation servers. This speeds up the  delivery
       of compilations by up to	an order of magnitude over plain distcc.

       Compilation  is	driven by a client machine, which is typically the de-
       veloper's workstation or	laptop.	 The distcc client runs	 on  this  ma-
       chine,  as  does	 make,	the preprocessor (if distcc's pump mode	is not
       used), the linker, and other stages of the build	process.   Any	number
       of volunteer machines act as compilation	servers	and help the client to
       build the program, by running the distccd(1) daemon, C compiler and as-
       sembler as required.

       distcc  can run across either TCP sockets (on port 3632 by default), or
       through a tunnel	command	such as	ssh(1).	 For TCP connections the  vol-
       unteers	must  run the distccd(1) daemon	either directly	or from	inetd.
       For SSH connections distccd must	be installed but should	not be listen-
       ing for connections.

       TCP connections should only be used on secure networks because there is
       no user authentication or protection of source  or  object  code.   SSH
       connections  are	typically 25% slower because of	processor overhead for
       encryption, although this can vary greatly depending on	CPUs,  network
       and the program being built.

       distcc  is  intended  to	 be used with GNU Make's -j option, which runs
       several compiler	 processes  concurrently.   distcc  spreads  the  jobs
       across  both local and remote CPUs.  Because distcc is able to distrib-
       ute most	of the work across the network,	a higher concurrency level can
       be used than for	local builds.  As a rule of thumb, the -j value	should
       be set to about twice the total number of  available  server  CPUs  but
       subject	to client limitations.	This setting allows for	maximal	inter-
       leaving of tasks	being blocked waiting for disk	or  network  IO.  Note
       that  distcc  can  also	work  with  other build	control	tools, such as
       SCons, where similar concurrency	settings must be adjusted.

       The -j setting, especially for large values of -j, must take  into  ac-
       count the CPU load on the client.  Additional measures may be needed to
       curtail the client load.	 For example, concurrent linking should	be se-
       verely  curtailed using auxiliary locks.	 The effect of other build ac-
       tivity, such as Java compilation	when building mixed  code,  should  be
       considered.   The  --localslots_cpp  parameter is by default set	to 16.
       This limits the number of concurrent processes that do preprocessing in
       plain  distcc (non-pump)	mode.  Therefore, larger -j values than	16 may
       be used without overloading a single-CPU	client due  to	preprocessing.
       Such large values may speed up parts of the build that do not involve C
       compilations, but they may not be useful	to distcc efficiency in	 plain

       In  contrast,  using pump mode and say 40 servers, a setting of -j80 or
       larger may be appropriate even for single-CPU clients.

       It is strongly recommended that you install the same  compiler  version
       on  all	machines participating in a build.  Incompatible compilers may
       cause mysterious	compile	or link	failures.

       1      For each machine,	download distcc, unpack, and install.

       2      On each of the servers, run distccd --daemon  with  --allow  op-
	      tions to restrict	access.

       3      Put the names of the servers in your environment:
	      $	export DISTCC_HOSTS='localhost red green blue'

       4      Build!
	      $	make -j8 CC=distcc

       Proceed	as  above, but in Step 3, specify that the remote hosts	are to
       carry the burden	of preprocessing and that the files sent over the net-
       work should be compressed:

	      $	  export   DISTCC_HOSTS='--randomize   localhost   red,cpp,lzo
	      green,cpp,lzo blue,cpp,lzo'

       The --randomize option enforces a uniform  usage	 of  compile  servers.
       While you will get some benefit from distcc's pump mode with only a few
       servers,	you get	increasing benefit with	more server CPUs  (up  to  the
       hundreds!).   Wrap your build inside the	pump command, here assuming 10

	      $	pump make -j20 CC=distcc

       distcc only ever	runs the compiler and assembler	remotely.  With	 plain
       distcc,	the  preprocessor  must	always run locally because it needs to
       access various header files on the  local  machine  which  may  not  be
       present,	 or  may  not be the same, on the volunteer.  The linker simi-
       larly needs to examine libraries	and object files, and so must run  lo-

       The  compiler  and assembler take only a	single input file (the prepro-
       cessed source) and produce a single output (the object  file).	distcc
       ships these two files across the	network	and can	therefore run the com-
       piler/assembler remotely.

       Fortunately, for	most programs running the preprocessor	is  relatively
       cheap,  and  the	linker is called relatively infrequent,	so most	of the
       work can	be distributed.

       distcc examines its command line	to determine which of these phases are
       being invoked, and whether the job can be distributed.

       In pump mode, distcc runs the preprocessor remotely too.	 To do so, the
       preprocessor must have access to	all the	files that it would  have  ac-
       cessed  if  had	been running locally.  In pump mode, therefore,	distcc
       gathers all of the recursively included headers,	except the  ones  that
       are  default  system headers, and sends them along with the source file
       to the compilation server.

       In distcc-pump mode, the	server unpacks the set of all source files  in
       a temporary directory, which contains a directory tree that mirrors the
       part of the file	system that is relevant	 to  preprocessing,  including
       symbolic	links.

       The  compiler is	then run from the path in the temporary	directory that
       corresponds to the current working directory on the  client.   To  find
       and transmit the	many hundreds of files that are	often part of a	single
       compilation, pump mode uses an incremental include analysis  algorithm.
       The  include server is a	Python program that implements this algorithm.
       The pump	command	starts the include server so that throughout the build
       it can answer include queries by	distcc commands.

       The  include  server uses static	analysis of the	macro language to deal
       with conditional	compilation and	computed includes.  It uses the	 prop-
       erty  that  when	 a given header	file has already been analyzed for in-
       cludes, it is not necessary to do so again if all the  include  options
       (-I's) are unchanged (along with	other conditions).

       For  large  builds,  header files are included, on average, hundreds of
       times each. With	distcc-pump mode each such file	is analyzed only a few
       times,  perhaps	just  once,  instead of	being preprocessed hundreds of
       times.  Also, each source or header file	is now compressed  only	 once,
       because the include server memoizes the compressed files.  As a result,
       the time	used for preparing compilations	may drop by up to an order  of
       magnitude over the preprocessing	of plain distcc.

       Because	distcc	in pump	mode is	able to	push out files up to about ten
       times faster, build speed may increase 3X or more for large builds com-
       pared to	plain distcc mode.

       Using  pump mode	requires both client and servers to use	release	3.0 or
       later of	distcc and distccd (respectively).

       The incremental include analysis	of distc-pump mode rests on the	funda-
       mental assumption that source and header	files do not change during the
       build process.  A few complex build systems, such  as  that  for	 Linux
       kernel  2.6,  do	 not quite satisfy this	requirement.  To overcome such
       issues, and other corner	cases such as absolute filepaths in  includes,
       see the include_server(1) man page.

       Another	important  assumption is that the include configuration	of all
       machines	must be	identical.  Thus the headers under the default	system
       path  must  be  the same	on all servers and all clients.	 If a standard
       GNU compiler installation is used, then this requirement	applies	to all
       libraries  whose	 header	 files	are  installed	under  /usr/include or
       /usr/local/include/.  Note that installing software packages often lead
       to additional headers files being placed	in subdirectories of either.

       If  this	 assumption does not hold, then	it is possible to break	builds
       with distcc-pump	mode, or worse,	to get wrong results without  warning.
       Presently this condition	is not verified, and it	is on our TODO list to
       address this issue.

       An easy way to guarantee	that the include configurations	are  identical
       is  to  use  a cross-compiler that defines a default system search path
       restricted to directories of the	compiler installation.

       See the include_server(1) manual	for more information on	 symptoms  and
       causes of violations of distcc-pump mode	assumptions.

       Most options passed to distcc are interpreted as	compiler options.  The
       following options are understood	by distcc itself.  If any of these op-
       tions are specified, distcc will	not invoke the compiler.

       --help Displays summary instructions.

	      Displays the distcc client version.

	      Displays	the  host  list	 that  distcc would use.  See the Host
	      Specifications section.

	      Displays the list	of files that distcc would send	to the	remote
	      machine, as computed by the include server.  This	is a conserva-
	      tive (over-)approximation	of the files that would	be read	by the
	      C	 compiler.  This option	only works in pump mode.  See the "How
	      Distcc-pump Mode Works" section for details on how this is  com-

	      The list output by distcc	--scan-includes	will contain one entry
	      per line.	 Each line contains a category	followed  by  a	 path.
	      The category is one of FILE, SYMLINK, DIRECTORY, or SYSTEMDIR:

	      FILE  indicates  a source	file or	header file that would be sent
	      to the distcc server host.

	      SYMLINK indicates	a symbolic link	that  would  be	 sent  to  the
	      distcc server host.

	      DIRECTORY	 indicates  a directory	that may be needed in order to
	      compile the source file.	For example, a directory "foo" may  be
	      needed   because	 of   an   include   of	  the	form  #include
	      "foo/../bar.h".  Such directories	would be created on the	distcc
	      server host.

	      SYSTEMDIR	indicates a system include directory, i.e. a directory
	      which is	on  the	 compiler's  default  include  path,  such  as
	      "/usr/include";  such  directories  are assumed to be present on
	      the distcc server	host, and so would not be sent to  the	distcc
	      server host.

       -j     Displays distcc's	concurrency level, as calculated from the host
	      list; it is the maximum number of	 outstanding  jobs  issued  by
	      this  client to all servers.  By default this will be four times
	      the number of hosts in the host list, unless the	/LIMIT	option
	      was used in the host list.  See the Host Specifications section.

       There  are  three different ways	to call	distcc,	to suit	different cir-

	      distcc can be installed under the	name of	the real compiler,  to
	      intercept	calls to it and	run them remotely.  This "masqueraded"
	      compiler has  the	 widest	 compatibility	with  existing	source
	      trees,  and  is  convenient  when	you want to use	distcc for all
	      compilation.  The	fact that distcc is being used is  transparent
	      to the makefiles.

	      distcc  can  be  prepended  to  compiler	command	lines, such as
	      "distcc cc -c hello.c" or	CC="distcc gcc".  This	is  convenient
	      when you want to use distcc for only some	compilations or	to try
	      it out, but can cause trouble with some makefiles	or versions of
	      libtool that assume $CC does not contain a space.

	      Finally, distcc can be used directly as a	compiler.  "cc"	is al-
	      ways used	as the name of the real	compiler  in  this  "implicit"
	      mode.   This  can	 be  convenient	 for interactive use when "ex-
	      plicit" mode does	not work but is	not really recommended for new

       Remember	 that you should not use two methods for calling distcc	at the
       same time.  If you are using a masquerade directory,  don't  change  CC
       and/or  CXX,  just put the directory early on your PATH.	 If you're not
       using a masquerade directory, you'll need to either  change  CC	and/or
       CXX, or modify the makefile(s) to call distcc explicitly.

       The  basic  idea	 is  to	create a "masquerade directory"	which contains
       links from the name of the real compiler	to the	distcc	binary.	  This
       directory  is inserted early on the PATH, so that calls to the compiler
       are intercepted and distcc is run instead.  distcc then removes	itself
       from the	PATH to	find the real compiler.

       For example:

	      #	mkdir /usr/lib/distcc/bin
	      #	cd /usr/lib/distcc/bin
	      #	ln -s ../../../bin/distcc gcc
	      #	ln -s ../../../bin/distcc cc
	      #	ln -s ../../../bin/distcc g++
	      #	ln -s ../../../bin/distcc c++

       Then,   to  use	distcc,	 a  user  just	needs  to  put	the  directory
       /usr/lib/distcc/bin early in the	PATH, and have	set  a	host  list  in
       DISTCC_HOSTS or a file.	distcc will handle the rest.

       Note that this masquerade directory must	occur on the PATH earlier than
       the directory that contains the actual compilers	of the same names, and
       that  any  auxiliary  programs that these compilers call	(such as as or
       ld) must	also be	found on the PATH in a directory after the  masquerade
       directory since distcc calls out	to the real compiler with a PATH value
       that has	all directory up to and	 including  the	 masquerade  directory
       trimmed off.

       It  is  possible	 to  get a "recursion error" in	masquerade mode, which
       means that distcc is somehow finding itself again, not  the  real  com-
       piler.	This  can indicate that	you have two masquerade	directories on
       the PATH, possibly because of having two	distcc installations  in  dif-
       ferent locations.  It can also indicate that you're trying to mix "mas-
       queraded" and "explicit"	operation.

       Recursion errors	can be avoided	by  using  shell  scripts  instead  of
       links.  For example, in /usr/lib/distcc/bin create a file cc which con-

	      distcc /usr/bin/gcc "$@"

       In this way, we are not dependent on distcc having to locate  the  real
       gcc  by investigating the PATH variable.	Instead, the compiler location
       is explicitly provided.

       ccache is a program that	speeds software	builds by caching the  results
       of  compilations.  ccache is normally called before distcc, so that re-
       sults are retrieved from	a normal cache.	 Some experimentation  may  be
       required	for idiosyncratic makefiles to make everything work together.

       The most	reliable method	is to set


       This  tells ccache to run distcc	as a wrapper around the	real compiler.
       ccache still uses the real compiler to detect compiler upgrades.

       ccache  can then	be run using either a masquerade directory or by  set-

	      CC="ccache gcc"

       As  of version 2.2, ccache does not cache compilation from preprocessed
       source and so will never	get a cache hit	if it is run from  distccd  or
       distcc.	It must	be run only on the client side and before distcc to be
       any use.

       distcc's	pump mode is not compatible with ccache.

       A "host list" tells distcc which	machines to use	for  compilation.   In
       order,  distcc  looks  in  the  $DISTCC_HOSTS environment variable, the
       user's $DISTCC_DIR/hosts	file, and the system-wide host	file.	If  no
       host list can be	found, distcc emits a warning and compiles locally.

       The  host list is a simple whitespace separated list of host specifica-
       tions.  The simplest and	most common form is a host names, such as

	      localhost	red green blue

       distcc prefers hosts towards the	start of the list, so machines	should
       be  listed  in  descending  order of speed.  In particular, when	only a
       single compilation can be run (such as from a  configure	 script),  the
       first machine listed is used (but see --randomize below).

       Placing	localhost  at the right	point in the list is important to get-
       ting good performance.  Because overhead	for running  jobs  locally  is
       low, localhost should normally be first.	 However, it is	important that
       the client have enough cycles free to run the local jobs	and the	distcc
       client.	 If  the client	is slower than the volunteers, or if there are
       many volunteers,	then the client	should be put later in the list	or not
       at all.	As a general rule, if the aggregate CPU	speed of the client is
       less than one fifth of the total, then the client should	be left	out of
       the list.

       If  you	have  a	 large	shared build cluster and a single shared hosts
       file, the above rules would cause the first few machines	in  the	 hosts
       file  to	 be  tried first even though they are likely to	be busier than
       machines	later in the list.  To avoid this, place the keyword --random-
       ize  into  the  host list.  This	will cause the host list to be random-
       ized, which should improve performance slightly for large  build	 clus-

       There  are  two	special	 host  names --localslots and --localslots_cpp
       which are useful	for adjusting load on the local	machine.  The --local-
       slots host specifies how	many jobs that cannot be run remotely that can
       be run concurrently on the local	machine, while	--localslots_cpp  con-
       trols how many preprocessors will run in	parallel on the	local machine.
       Tuning these values can improve performance.  Linking on	large projects
       can take	large amounts of memory.  Running parallel linkers, which can-
       not be executed remotely,  may force the	machine	to swap, which reduces
       performance  over  just	running	the jobs in sequence without swapping.
       Getting the number of parallel preprocessors just right allows  you  to
       use  larger parallel factors with make, since the local machine now has
       some machanism for measuring local resource usage.

       Finally there is	the host entry

       Performance depends on the details of the source	and makefiles used for
       the  project,  and  the machine and network speeds.  Experimenting with
       different settings for the host list and	-j factor may improve  perfor-

       The syntax is

			       | GLOBAL_OPTION
			       | ZEROCONF
	 LOCAL_HOST = localhost[/LIMIT]
		    | --localslots=<int>
		    | --localslots_cpp=<int>
	 OPTION	= lzo |	cpp
	 GLOBAL_OPTION = --randomize
	 ZEROCONF = +zeroconf

       Here are	some individual	examples of the	syntax:

	      The  literal  word "localhost" is	interpreted specially to cause
	      compilations to be directly executed, rather than	 passed	 to  a
	      daemon  on  the  local  machine.	If you do want to connect to a
	      daemon on	the local machine for testing, then give the machine's
	      IP address or real hostname.  (This will be slower.)

       IPV4   A	literal	IPv4 address, such as

	      A	hostname to be looked up using the resolver.

       :PORT  Connect  to a specified decimal port number, rather than the de-
	      fault of 3632.

	      Connect to the host over SSH, rather than	TCP.  Options for  the
	      SSH connection can be set	in ~/.ssh/config

       USER@  Connect to the host over SSH as a	specified username.

	      Connect  over  SSH, and use a specified path to find the distccd
	      server.  This is normally	only needed if	for  some  reason  you
	      can't  install  distccd into a directory on the default PATH for
	      SSH connections.	Use this if you	get errors like	"distccd: com-
	      mand not found" in SSH mode.

       /LIMIT A	 decimal  limit	 can be	added to any host specification	to re-
	      strict the number	of jobs	that this client will send to the  ma-
	      chine.  The limit	defaults to four per host (two for localhost),
	      but may be further restricted by the server.   You  should  only
	      need to increase this for	servers	with more than two processors.

       ,lzo   Enables LZO compression for this TCP or SSH host.

       ,cpp   Enables distcc-pump mode for this	host.  Note: the build command
	      must be wrapped in the pump script in order to start the include

	      Randomize	the order of the host list before execution.

	      This  option is only available if	distcc was compiled with Avahi
	      support enabled at configure time.  When this special  entry  is
	      present  in  the	hosts list, distcc will	use Avahi Zeroconf DNS
	      Service Discovery	 (DNS-SD)  to  locate  any  available  distccd
	      servers  on  the local network.  This avoids the need to explic-
	      itly list	the host names or IP addresses of  the	distcc	server
	      machines.	  The  distccd servers must have been started with the
	      "--zeroconf" option to distccd.  An important caveat is that  in
	      the  current  implementation, pump mode (",cpp") and compression
	      (",lzo") will never be used for hosts located via	zeroconf.

       Here is an example demonstrating	some possibilities:

	      localhost/2 @bigman/16:/opt/bin/distccd oldmachine:4200/1
	      #	cartman	is down

       Comments	are allowed in host specifications.   Comments	start  with  a
       hash/pound sign (#) and run to the end of the line.

       If  a  host in the list is not reachable	distcc will emit a warning and
       ignore that host	for about one minute.

       The lzo host option specifies that LZO compression should be  used  for
       data  transfer,	including  preprocessed	 source, object	code and error
       messages.  Compression is usually economical on	networks  slower  than
       100Mbps,	 but results may vary depending	on the network,	processors and
       source tree.

       Enabling	compression makes the distcc client and	server	use  more  CPU
       time,  but  less	 network traffic.  The added CPU time is insignificant
       for pump	mode.  The compression ratio is	typically 4:1 for  source  and
       2:1 for object code.

       Using  compression  requires both client	and server to use at least re-
       lease 2.9 of distcc.  No	server configuration is	required:  the	server
       always responds with compressed replies to compressed requests.

       Pump mode requires the servers to have the lzo host option on.

       If  the compiler	name is	an absolute path, it is	passed verbatim	to the
       server and the compiler is run from that	directory.  For	example:

	      distcc /usr/local/bin/gcc-3.1415 -c hello.c

       If the compiler name is not absolute, or	not fully qualified, distccd's
       PATH is searched.  When distcc is run from a masquerade directory, only
       the base	name of	the compiler is	used.  The client's PATH is used  only
       to run the preprocessor and has no effect on the	server's path.

       Both  the  distcc client	and server impose timeouts on transfer of data
       across the network.  This is intended to	detect hosts which are down or
       unreachable,  and  to prevent compiles hanging indefinitely if a	server
       is disconnected while in	use.  If a client-side	timeout	 expires,  the
       job will	be re-run locally.

       The timeouts are	not configurable at present.

       Error  messages	or  warnings from local	or remote compilers are	passed
       through to diagnostic output on the client.

       distcc can supply extensive debugging information when the verbose  op-
       tion  is	 used.	 This  is controlled by	the DISTCC_VERBOSE environment
       variable	on the client, and the --verbose option	on  the	 server.   For
       troubleshooting,	examine	both the client	and server error messages.

       The exit	code of	distcc is normally that	of the compiler: zero for suc-
       cessful compilation and non-zero	otherwise.

       distcc distinguishes between "genuine" errors such as a syntax error in
       the  source,  and "accidental" errors such as a networking problem con-
       necting to a volunteer.	In the case of accidental errors, distcc  will
       retry  the  compilation	locally	 unless	the DISTCC_FALLBACK option has
       been disabled.

       If the compiler exits with a signal, distcc returns an exit code	of 128
       plus the	signal number.

       distcc internal errors cause an exit code between 100 and 127.  In par-

       100    General distcc failure.

       101    Bad arguments.

       102    Bind failed.

       103    Connect failed.

       104    Compiler crashed.

       105    Out of memory.

       106    Bad Host SPEC

       107    I/O Error

       108    Truncated.

       109    Protocol Error.

       110    The given	compiler was not found on the remote host.  Check that
	      $CC  is set appropriately	and that it's installed	in a directory
	      on the search path for distccd.

       111    Recursive	call to	distcc.

       112    Failed to	discard	privileges.

       113    Network access denied.

       114    In use by	another	process.

       115    No such file.

       116    No hosts defined and fallbacks disabled.

       118    Timeout.

       If $DISTCC_HOSTS	is not set, distcc  reads  a  host  list  from	either
       $DISTCC_DIR/hosts  or  a	 system-wide configuration file	set at compile
       time.  The file locations are shown in the output from distcc --help

       distcc creates a	number of temporary and	lock files underneath the tem-
       porary directory.

       distcc's	 behaviour is controlled by a number of	environment variables.
       For most	cases nothing need be set if the host  list  is	 stored	 in  a

	      Space-separated list of volunteer	host specifications.

	      If  set  to 1, distcc produces explanatory messages on the stan-
	      dard error stream	or in the log file.  This can  be  helpful  in
	      debugging	problems.  Bug reports should include verbose output.

	      Log  file	 to  receive  messages from distcc itself, rather than

	      By default distcc	will compile locally if	it fails to distribute
	      a	 job to	the intended machine, or if no host list can be	found.
	      If this variable is set to 0 then	 fallbacks  are	 disabled  and
	      those  compilations  will	 simply	fail.  Note that this does not
	      affect jobs which	must always be local such as linking.

	      If set to	1, temporary files are not deleted  after  use.	  Good
	      for debugging, or	if your	disks are too empty.

	      If set to	0, disable use of "TCP corks", even if they're present
	      on this system.  Using corks normally helps pack	requests  into
	      fewer  packets  and  aids	 performance.  This should normally be
	      left enabled.

	      Specifies	the command used for  opening  SSH  connections.   De-
	      faults to	"ssh" but may be set to	a different connection command
	      such as "lsh" or "tsocks-ssh" that  accepts  a  similar  command
	      line.   The  command is not split	into words and is not executed
	      through the shell.

	      Per-user configuration directory to store	lock files  and	 state
	      files.  By default ~/.distcc/ is used.

       TMPDIR Directory	 for  temporary	files such as preprocessor output.  By
	      default /tmp/ is used.

	      If set and if DISTCC_LOG is not set, distcc errors  are  written
	      to  the file descriptor identified by this variable.  This vari-
	      able is intended mainly for automatic use	by ccache, which  sets
	      it to avoid caching transient errors such	as network problems.

	      If  set,	distcc	sends  an  email when a	compilation failed re-
	      motely, but succeeded locally.  Built-in heuristics prevent some
	      such  discrepancy	email from being sent if the problem is	that a
	      local file changed between the failing  remote  compilation  and
	      the succeeding local compilation.

	      The email	address	for discrepancy	email; the default is "distcc-

       Cross compilation means building	programs to run	on a  machine  with  a
       different  processor,  architecture,  or	operating system to where they
       were compiled.  distcc supports cross compilation, including  teams  of
       mixed-architecture  machines,  although some changes to the compilation
       commands	may be required.

       The compilation command passed to distcc	must be	one that will  execute
       properly	 on  every  volunteer machine to produce an object file	of the
       appropriate type.  If the machines have different processors, then sim-
       ply  using distcc cc will probably not work, because that will normally
       invoke the volunteer's native compiler.

       Machines	with the same CPU but different	operating systems may not nec-
       essarily	generate compatible .o files.

       Several	different  gcc configurations can be installed side-by-side on
       any machine.  If	you build gcc from source, you should use  the	--pro-
       gram-suffix  configuration  options  to cause it	to be installed	with a
       name that encodes the gcc version and the target	platform.

       The recommended convention for the gcc name is TARGET-gcc-VERSION  such
       as  i686-linux-gcc-3.2  .  GCC 3.3 will install itself under this name,
       in addition to TARGET-gcc and, if it's native, gcc-VERSION and gcc .

       The compiler must be installed under the	same name on the client	and on
       every volunteer machine.

       If  you think you have found a  distcc bug, please see the file report-
       ing-bugs.txt in the documentation directory for information on  how  to
       report it.

       Some  makefiles have missing or extra dependencies that cause incorrect
       or slow parallel	builds.	 Recursive make	is inefficient and  can	 leave
       processors  unnecessarily  idle	for long periods.  (See	Recursive Make
       Considered Harmful by Peter Miller.)  Makefile bugs are the most	common
       cause  of  trees	 failing  to build under distcc.  Alternatives to Make
       such as SCons can give much faster builds for some projects.

       Using different versions	of gcc can cause confusing build problems  be-
       cause  the  header  files and binary interfaces have changed over time,
       and some	distributors have included incompatible	patches	without	chang-
       ing  the	 version number.  distcc does not protect against using	incom-
       patible versions.  Compiler errors about	link problems or  declarations
       in system header	files are usually due to mismatched or incorrectly in-
       stalled compilers.

       gcc's -MD option	can produce output  in	the  wrong  directory  if  the
       source and object files are in different	directories and	the -MF	option
       is not used.  There is no  perfect  solution  because  of  incompatible
       changes	between	 gcc  versions.	  Explicitly specifying	the dependency
       output file with	-MF will fix the problem.

       TCP mode	connections should only	be used	on trusted networks.

       Including slow machines in the list of volunteer	 hosts	can  slow  the
       build down.

       When  distcc  or	ccache is used on NFS, the filesystem must be exported
       with the	no_subtree_check option	to allow reliable renames between  di-

       The  compiler  can  be  invoked with a command line gcc hello.c to both
       compile and link.  distcc doesn't split this into separate  parts,  but
       rather runs the whole thing locally.

       distcc-pump  mode  reverts  to  plain distcc mode for source files that
       contain includes	with absolute paths (either directly or	in an included

       Due  to	limitations  in	gcc, gdb may not be able to automatically find
       the source files	for programs built using distcc	in some	circumstances.
       The  gdb	 directory command can be used.	 For distcc's plain (non-pump)
       mode, this is fixed in gcc 3.4 and later.  For pump mode,  the  fix  in
       gcc  3.4	 does  not  suffice; we've worked around the gcc limitation by
       rewriting the object files that gcc produces, but this is only done for
       ELF object files, but not for other object file formats.

       The  .o	files  produced	 by  discc in pump mode	will be	different from
       those produced locally: for non-ELF files, the debug  information  will
       specify	compile	 directories of	the server.  The code itself should be

       For the ELF-format, distcc rewrites the .o files	to correct compile di-
       rectory	path  information.  While the resulting	.o files are not byte-
       wise identical to what would have been produced by compiling on the lo-
       cal client (due to different padding, etc), they	should be functionally

       In distcc-pump mode, the	include	server is  unable  to  handle  certain
       very  complicated  computed includes as found in	parts of the Boost li-
       brary. The include server will time out and distcc will revert to plain

       In  distcc-pump	mode,  certain	assumptions  are  made that source and
       header files do not change during the build.  See discussion in section
       DISTCC DISCREPANCY SYMPTOMS of include_server(1().

       Other known bugs	may be documented on

       distcc was written by Martin Pool <>, with the	co-op-
       eration of many scholars	including Wayne	Davison, Frerich  Raabe,  Dim-
       itri  Papadopoulos  and	others	noted in the NEWS file.	 Please	report
       bugs to <>.  See pump(1) for the authors of  pump

       You  are	 free  to  use	distcc.	 distcc	(including this	manual)	may be
       copied, modified	or distributed only under the terms of the GNU General
       Public  Licence	version	 2  or later.  distcc comes with absolutely no
       warrany.	 A copy	of the GPL is included in the file COPYING.

       distccd(1),   pump(1),	include_server(1),   gcc(1),   make(1),	   and

				  9 June 2008			     distcc(1)


Want to link to this manual page? Use this URL:

home | help