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 slower.

       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 8.
       This limits the number of concurrent processes that do preprocessing in
       plain  distcc  (non-pump) mode.	Therefore, larger -j values than 8 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

       Proceed as per the QUICKSTART but in Step 3, specify  that  the	remote
       hosts are to mutually authenticate with the client:

	      $	export DISTCC_HOSTS='--randomize localhost red,auth green,auth

       If distccd runs under a specific	principal name then execute  the  fol-
       lowing command prior to step 4:

	      export DISTCC_PRINICIPAL=<name>

       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.

       In this mode distcc will	use the	GSS-API	framework to access  the  cur-
       rently  configured security mechanism and perform mutual	authentication
       with the	daemon.

       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 or-
		     der 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 cre-
		     ated 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  as-
		     sumed  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.

	      Displays the name	of the distccd	security  principal  extracted
	      from  the	 environment.  This option is only available if	distcc
	      was compiled with	the --with-auth	configure option.

       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.

       To automatically	discover compilers and create masquerade links run the
       provided	update-distcc-symlinks script.

       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 mechanism 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 | auth[=AUTH_NAME]
	 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.)

       IPV6   A	 literal  IPv6	address	 enclosed  in square brackets, such as

       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

       ,auth  Enables GSSAPI-based mutual authentication for this host.

	      The "canonical" name to use for the service principal  name  in-
	      stead  of	 HOSTNAME  (or its corresponding fqdn).	This option is
	      useful in	case of	accessing an authenticated server via ssh port
	      forwarding, in which case	the HOSTNAME is

	      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  transfer  timeout is not configurable at present. The timeout that
       detects stale distributed job is	configurable via DISTCC_IO_TIMEOUT en-
       vironment variable.

       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.

       119    GSS-API -	Catchall error code for	GSS-API	related	errors.

       120    Called for preprocessing,	which needs to be done locally.

       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.

	      By default distcc	will rewrite calls gcc to use fully  qualified
	      names  (like x86_64-linux-gnu-gcc), and clang to use the -target
	      option. Setting this turns that off.

	      Specifies	how long (in seconds) distcc will avoid	trying to  use
	      a	 particular compilation	server after that server yields	a com-
	      pile failure.  By	default	set to 60  seconds.   To  disable  the
	      backoff behavior altogether, set this to 0.

	      Specifies	how long (in seconds) distcc will wait before deciding
	      a	distributed job	has timed out.	If a distributed  job  is  ex-
	      pected  to  takes	a long time, consider increasing this value so
	      the job does not time out	and fallback to	a local	 compile.   By
	      default set to 300 seconds.

	      Specifies	 how long (in milliseconds) distcc will	pause when all
	      compilation servers are in use.  By default  set	to  1000  mil-
	      liseconds	 (1 second).  Setting this to a	smaller	value (e.g. 10
	      milliconds) may improve throughput for some  configurations,  at
	      the expense of increased CPU load	on the distcc client machine.

	      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.

	      If  set,	when a remote compile fails, distcc will no longer try
	      to recompile that	file locally.

	      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  maximum  number  of	remote compilation failures allowed in
	      pump mode	before distcc switches to plain	distcc	mode.  By  de-
	      fault set	to 1.

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

	      If set, specifies	the name of the	principal  that	 distccd  runs
	      under,  and  is  used  to	authenticate the server	to the client.
	      This environment variable	is only	used if	 distcc	 was  compiled
	      with the --with-auth configure option and	the ,auth per host op-
	      tion is specified.

       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