[distcc] Re: distcc CVS

Martin Pool mbp at samba.org
Mon Nov 11 08:03:01 GMT 2002


On 11 Nov 2002, Tim Janik <timj at gtk.org> wrote:

> > > the only real solution i can come up with at this point, is
> > > to ensure that all pathnames which end up in the object file
> > > are absolute. this gets us around `basename $inputfile` relative
> > > file names, and around gcc-cwd relative file names.
> >
> > Just giving cpp an absolute filename on the command line seems to make
> > all of the # lines in the output be absolute.
> 
> this doesn't seem to be an option for normal automake usages (i.e.
> projects besides samba).

Yes, but it would be straightforward for distcc to absolutify the
source filename when running "cc -E".  Changing

 cc hello.c

into
 
 cc -E /home/mbp/work/distcc/src/cases/hello.c 

to get the source would be easy, and would make all paths output by
cpp be absolute.

> yes, and some projects make heavy use of __FILE__ where absolute
> pathnames can be quite disturbing.

If we wanted to avoid that, it would seem that the only way is to
postprocess the cpp source.

> > Postprocessing the cpp output has the advantage of not mangling
> > __FILE__ lines, but at the cost of probably being more complex,
> > slower, and perhaps at risk of corrupting the source.  Given that it
> > doesn't produce exactly the same .o as local, I am inclined to hold
> > off in the hope of a better idea.

> i'm not so sure about this corrupting the source, because the '#'
> directives are pretty easy and reliably catchable.

I don't think there a huge risk of corrupting the source, and as you
say the necessary edits are straightforward.  My concern is just
"what's not there can't break".

> about the same .o as local, the very problem is the remote
> compilation not producing the same .o as local in the first place,
> so aside from improved debugging behaviour, i don't see how this
> makes the .o any better or worse.

That's true.

> i'll use the patch on a daily basis now, and i've
> put up an improved and cleaned up version at
> 
>   http://www.gtk.org/~timj/patches/
> 
> so others may give it a try.

I'll check it out.  I think I will not put it in the next release,
because there are many other things waiting to go, but perhaps
something like this can go in after that.

> before you start out with LD_PRELOAD/chroot measures, it might be
> easier and more reliable to simply get the gcc team into accepting a
> 
> >  - chdir the compiler into the right directory; complain if it doesn't
> >    exist or can't be created
> 
> hm, that wouldn't be a viable alternative in my case and probably not
> so for a couple other users.

Yes, I know.

> >  - complain to the gcc maintainers that they should take the directory
> >    from cpp, not gcc's pwd
> 
> i don't understand how that should work. cpp doesn't pass it's pwd
> on to gcc, there's no mechanism for that in the preprocessed source.

It would require changes to both cpp and gcc (and users would need to
upgrade both ends.)  One of the gcc maintainers suggested something
like

  # <dir> "/home/mbp/work/gcc"

etc.

-- 
Martin

"Those who are familiar with Open Source Software and Linux are
favorably predisposed towards them."
	-- Microsoft white paper, 
	   http://www.opensource.org/halloween/halloween7.php



More information about the distcc mailing list