This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [distcc] using distcc to speed up gcc bootstraps


On Aug 14, 2002, Martin Pool <mbp@samba.org> wrote:

> I can see how including the pwd is useful for making gdb more
> friendly, but it seems kind of tacky at the same time, by putting a
> kind of "hidden variable" into the .o file.  

I agree.  I have confirmed that this is the reason for the
differences, and I've managed to avoid them by making sure I start
distccd on all of the build servers while being in the same directory
(say /tmp), and then *not* listing localhost in DISTCC_HOSTS (using
the local host name instead).

> If you have to do it, it seems to me that it would be cleaner to make
> cpp resolve the absolute path of the input file, and put that in to a
> # directive, either replacing the existing ones or otherwise.

An alternative I'm considering is to have cpp emit some different #
directive that contains the full pathname of the source file, or
perhaps just the directory name.  I.e., something like:

# 1 "filename"
# 1 "<directory> /path/name"
# 1 "filename"
...

I find this somewhat icky, but it's fully backward-compatible.  Neil,
Zack, anyone else, what do you think?


The other problem in libstdc++-v3 seems to be a bug in distcc:
libstdc++-v3 tries to runs .../xgcc -B.../ conftest.C -c -S.  The
distcc client writes the assembly output to conftest.o.  Curiously, if
I add `-o conftest.s' to the command line, it is the server that
fails, claiming it couldn't find conftest.C.  I haven't tracked it
down yet, but found a work-around: adding `ln -s conftest.o
conftest.s' just before the compilation in libstdc++-v3/configure.
With that, I managed to get a full bootstrap of binutils+gcc+gdb to
succeed.  Yay!

>> - the load on my build machine skyrockets while building the ada
>> compiler and the Java library. [...]  A lock on localhost, to be
>> used in such situations, would be ideal IMO.  Is this an acceptable
>> change for distcc?

> Yes, I think that would be very appropriate.  I would also like to
> make it take into account the load caused by jobs which turn out to be
> impossible to distribute, such as preprocessor or linker invocations.
> I have started on that for the next version.

Cool!  So, is there anything left for me to do regarding this feature,
or are you already taking care of all of it?  Let me know how I can
help.  I can't promise I'll have time for it, but I can always try :-)

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]