[distcc] Re: distcc CVS

[Martin Pool]

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

> not quite, i investigated this issue further, and while this fixes the
> path names to the original input file, it doesn't fix up relative
> includes like #include "../gdk/gdk.h".

I thought that might be the case.

> interestingly, these are not necessarily gcc-cwd relative, but
> `basename $inputfile` relative, which is a different thing if you
> compile sources like gcc tmp/foo.c.  the -I- option explaination in
> the gcc manual page mentions this.

I guess you can think of #line as setting the value of the item on
cpp's stack of include files.  It doesn't necessarily affect what's
stacked on top of it.

> > I wonder if we can count on cpp being able to feed from stdin, or if
> > we need to create another temporary file, being just the source with
> > this initial line?
> >
> > It may not interact well with cpp side effects like -MD, which care
> > about the name of the source file.
> 
> yes, i read your distcc comment about the -MD side effect with gcc pre-3.2.
> since i read that, i'm pondering another, more agressive solution ;)

> > If practical, I'd rather just have it always on, rather than
> > introducing another option.
> 
> well, it might be an expensive undertaking (read below) which is why
> it's probably a good idea to turn absolute pathnames on only if -g
> (or one of its variants) was detected in the input args.

I was also wondering about switching the behaviour based on -g.  The
tradeoff is between not modifying the file unless that is necessary,
and not making distcc's behaviour more complex than necessary.

> 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.  I think it avoids
breaking -MD and similar things.  It also avoids preprocessing the
output, which is (more important than speed) another potential point
of failure.

Making every filename absolute has at least two important
consequences: __FILE__ directives include the whole path, and debug
symbols include the whole path.  So gdb will break less badly, but any
error messages that use __FILE__ will look wierd.

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.

Other blue-sky ideas, probably not practical:

 - postprocess the object file using libbfd to make the compiler pwd
   "correct"

 - somehow mislead the compiler about its pwd (e.g. by an LD_PRELOAD)

 - chroot the compiler into the right directory

 - chdir the compiler into the right directory; complain if it doesn't
   exist or can't be created

 - complain to the gcc maintainers that they should take the directory
   from cpp, not gcc's pwd

 - ...?

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