distcc can not support the -I ,-isystem and -D... ???

[GoogleCodeExporter]

Answering the following questions is a big help:

1. What version of distcc are you using (e.g. "2.7.1")?  You can run "distcc 
--version" to see.  If you got distcc from a distribution package rather than 
building from source, please say which one.
--- distcc 3.2rc1 . i download the deb and install it using "dpkg".

2. What platform are you running on (e.g. "Red Hat 8.0", "HP-UX 11.11")?  What 
compilare are you using ("gcc 3.3")?  Run "uname -a" and "cc --version" to see.
---ubuntu 12.04  64 bit
3. What were you trying to do (e.g. "install distcc", "build Mozilla")?
---build the android4.1.1-r1 
4. What went wrong?  Did you get an error message, did it hang, did it build a 
program that didn't work, did it not distribute compilation to machines that 
ought to get it?
--- I think i have done all the necessary steps of distcc configuration. such 
as client config ,hosts ,and the cross-compile symbolink ,make command modify 
and so on.
 when the "make" is started ,i could get the information from distccd.log .some params is tranfered,but not all . I found that the 
params "-I" ,"-isystem","-DXX" ,"-MD","-MF" did NOT be transmit to distcc. I 
guess this the key why the distcc can not build succssed .But,i do not know why 
?Is this the bug of discc or unsuportted scenario ?or somewhere configuration 
missed?
by the wa ,i did not use pump mode ,neither ccache.

5. If you have an example of a compiler invocation that failed, quote it, in 
full e.g.:
----I tried to build the bootimage .the steps is following:
   1)./build/envsetup.sh
   2)make bootimage CC=distcc 
 I fetch the log of some file building (strlen.c) in order to highlight the error info . the command is attached also. (command.txt)

6. What error logging do you get?  Turn on client and server error logging.  On 
the client, set these environment variables, and try to reproduce the problem: 
=export DISTCC_VERBOSE=1 DISTCC_LOG=/tmp/distcc.log=.  Start the server with 
the --verbose option. If the problem is intermittent, leave logging enabled and 
then pull out the lines from the log file when the problem recurs.
----ok , the distcc.log and distccd.log are attached .
7. If you got an error message on stderr, quote that error exactly. Find the 
lines in the log files pertaining to the compile, and include all of them in 
your report, by looking at the process ID in square brackets. If you can't work 
that out, quote the last few hundred lines leading up to the failure.

thanks a lot and looking forward to your reply.

Original issue reported on code.google.com by xio...@gmail.com on 16 Feb 2013 at 9:39

• Merged into: #85

Attachments:

• command.txt
• distcc.log
• distccd.log

[GoogleCodeExporter]

> some params is tranfered,but not all . I found that the
> params "-I" ,"-isystem","-DXX" ,"-MD","-MF" did NOT be
> transmit to distcc.

These are preprocessor options.  Distcc runs the preprocessor (cpp) on the 
localhost before dispatching the task.  These options are deliberately removed 
before dispatching the remote task (distcc.log:18).

This is standard distcc operation and does not generally cause build failures.

> I guess this the key why the distcc can not build
> succssed .But,i do not know why ?

You will have to look at the STDERR from the remote host to know more why it 
failed.

Original comment by mand...@gmail.com on 16 Feb 2013 at 11:03

[GoogleCodeExporter]

Try "source ./build/envsetup.sh" instead of "./build/envsetup.sh".

Original comment by fergus.h...@gmail.com on 16 Feb 2013 at 1:24

[GoogleCodeExporter]

I notice that one of the arguments to the compiler is

@out/target/product/generic/obj/STATIC_LIBRARIES/libc_common_intermediates/impor
t_includes

I think this is the old DOS response file syntax, where the contents of that 
file is additional arguments to the compiler.

See related issue 85 
<http://code.google.com/p/distcc/issues/detail?id=85&q=response> which is about 
support for response files in pump mode.

Original comment by fergus.h...@gmail.com on 16 Feb 2013 at 2:04

[GoogleCodeExporter]

to mand...@gmail.com :
when i execute the command ,the STDERR is null. Maybe  all the info has been 
included in the distccd.log as i attached?

     to fergus.h...@gmail.com :
     i did not use the pump mode . And you mean that i should use the pump mode? ok,i will try.

Original comment by xio...@gmail.com on 18 Feb 2013 at 3:18

[GoogleCodeExporter]

to fergus.h...@gmail.com :
 well, i tried the pump mode and the log are attached .

 BTW, In my enviroment ,there are two machines. One is 195 ,the other is 132. 
 On 195, I installed both client and server ;on 132 ,i only installed  server .
 And the command of "make" is triggered on 195. That is why the attachments are involved distcc_195,distccd_195 and distccd_132. The rest of attachment(build_bootimage_pump) is the output of "make.." command.

I am not sure whether i could deploy the solution of 
<http://code.google.com/p/distcc/issues/detail?id=85&q=response> ,can you give 
me some advice? thank you .

Original comment by xio...@gmail.com on 18 Feb 2013 at 6:49

Attachments:

• pump_mode.7z

[GoogleCodeExporter]

hi, I just tried that ,when i took the @....../import_includes  out of the 
command line ,I really found that the positive signal in the distccd.log .
It seems that the @....../import_includes is the key.
Since the import_includes is necessary on my condition ,maybe i will modify the 
source of distcc and rebuild it..
I have consulted the  http://code.google.com/p/distcc/issues/detail?id=85 , but 
the patch seems to be not acceptable.
Can you give me some advice?
thank you very much.

Original comment by xio...@gmail.com on 18 Feb 2013 at 9:34

[GoogleCodeExporter]

> I have consulted the [issue 85], but the patch seems to be not acceptable.
> Can you give me some advice?

Another patch for that issue will be provided shortly.  The existing one is not 
acceptable for inclusion, but may be enough to resolve your issue if you apply 
it on your local copy.  There are some faults with its handling though, so use 
at your own risk.

Original comment by mand...@gmail.com on 18 Feb 2013 at 10:29

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Original comment by fergus.h...@gmail.com on 15 Apr 2013 at 9:42

• Changed state: Duplicate