Failed to send includes to include server using distcc-pump mode about distcc HOT 20 OPEN

I should add that I am in an environment with a NFS so all the header files are
common and available to any of the machines.

Is your code using Boost headers?
This warning

   WARNING include server: Preprocessing locally. Include server not covering:
   Bailing out because include server spent more than 3.8s user time handling
   request for translation unit 'cfilename.c

could be due to a known issue 
<http://code.google.com/p/distcc/issues/detail?id=16>.

Does this warning occur even for really simple code, e.g. an empty file, or a 
file
just containing "#include <stdio.h>"?
Try something like this

   echo "#include <stdio.h>" > foo.c
   pump distcc -c foo.c

and see if you still get the same message.

P.S. The distccd.log messages come from the lsdistcc call in the pump script; 
they
can safely be ignored.

Not using Boost headers, just standard .h files in a C source library.

Does this warning occur even for really simple code, e.g. an empty file, or a 
file
just containing "#include <stdio.h>"?
What happens if you try something like this?

   echo "#include <stdio.h>" > foo.c
   pump distcc -c foo.c

Running the tool on an empty file or foo.c as you mentioned works fine, it's 
only
when my own header files are included that I get the message: 

WARNING include server: Preprocessing locally. Include server not covering:
   Bailing out because include server spent more than 3.8s user time handling
   request for translation unit 'cfilename.c'

Sounds like this is probably another instance of issue 16.

You could try increasing USER_TIME_QUOTA in include_server/basics.py.

Increasing USER_TIME_QUOTA from 3.8 to 20 seems to give the include server the 
time
it needs and distcc gcc runs successfully. I guess I'll play around with it 
more to
find out the minimum time it needs?

Also, does pump-distcc mode use the same server for preprocessing and compiling 
each
time it runs? Or does it do each step on a different server and maybe they're 
the
same out of coincidence in the randomization?

With pump mode, preprocessing and compilation are done together, as a single 
step.
Gcc does that more efficiently if you do it as a single step - it doesn't need 
to
produce the intermediate preprocessed output file.

So pump mode knows this and doesn't send the output file to the remote server?

Yes, in pump mode distcc sends the source file and header files to the remote 
server, 
rather than preprocessing locally and sending the preprocessed output file to 
the
remote server.

Same thing being run....now I am failing to compile remotely everytime and I 
get this
message: 

__________Using distcc-pump from /home/tholly/solaris_local/bin
__________Found        3 available distcc servers
__________Warning:        1 pump-mode compilation(s) failed on server, but 
succeeded
locally.
__________Distcc-pump was demoted to plain mode.  See the Distcc Discrepancy 
Symptoms
section in the include_server(1) man page.
__________Shutting down distcc-pump include server

[deleted comment]

> 1 pump-mode compilation(s) failed on server, but succeeded locally.

In pump mode, distcc first tries compiling on the remote server.
If that fails, it retries the compilation locally.
If the local compilation succeeds, then it gives you the error message that you 
saw,
and for subsequent compilations (until you next invoke "pump" or "pump 
--startup"),
it will not attempt remote compilation.

You need to look at the other error messages to figure out why the compilation 
failed
remotely, but succeeded locally.

Off topic question...have you seen or heard of distcc working with the Diab 
compiler
called dcc?

Would it be possible for distcc to run other tools remotely like lint for 
example, or
an assember without a -c or -S option? I see that if a compiler does not have 
one of
these two options, it is automatically run on localhost.

It would be possible only if there is a way to cheaply precompute the set of 
files
that the tool will read (and the set it will write).  In the case of lint, that
should be the same as for the compiler, so it can be computed the same way.  In 
the
case of an assembler, it should typically be straight-forward, although it 
depends on
whether the assembly language supports anything similar to #include.

In addition, the tool would run in a different directory on a different host, 
so if
it embeds the hostname and/or directory in its outputs, that could cause some
problems.  But such problems should not be much of an issue, I expect, for lint 
or
for an assembler.

It would be great to restructure the code which parses the command line so that 
it we
can more easily plug in different parsers for different commands.

P.S. This question is really a bit off-topic for this bug report.
It's better to ask questions like these on the distcc mailing list
rather than via the distcc issues list.

Will do. Thanks.

[deleted comment]

[deleted comment]

system:
cygwin+ads

_______Using distcc-pump from /usr/local/bin
TRACE: Starting socketserver /tmp/distcc-pump.N13504/socket
__________Found 2 available distcc servers


WARNING include server: Preprocessing locally. Include server not covering: 
Could not 
locate name of translation unit: ['ARM926EJ-S', 
'/interwork/noropi/norwpi/noswst', 
'softvfp', '../../modem/1x/cp/src/otasp.c']. for translation unit 'unknown 
translation unit'
distcc[11132] Warning: include server gave up analyzing
distcc[11132] (dcc_build_somewhere) Warning: failed to get includes from 
include 
server, preprocessing locally
OBJECT SXNAAHZ/autoconfigdiag.o


why?how to fix this issue?

thanks a lot!

jason CNH