[distcc] Re: distcc CVS

[Tim Janik]

On Thu, 7 Nov 2002, Martin Pool wrote:

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

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

right, and it doesn't change the way items found in its search
path are treated.

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

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

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

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

the speed issue and extended point of failure (i.e. added complexity)
are what i think matter most. for the first, i switched the io buffering
from fputc/fgetc over to a couple lines inlined buffering code i have
been using in another project already, gaining a significant speed
improvement. for the second issue, testing is probably the only thing
that'll help us. 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.

> Other blue-sky ideas, probably not practical:
>
>  - postprocess the object file using libbfd to make the compiler pwd
>    "correct"

i don't know how feasible that is. i'm not sure though, that patching up
the .o file will be more reliable than patching up the preprocessing
directives. it could be a promising alternative if libbfd allowes for
that though.

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

i've been pondering that as well, but the possible breakage here in
interactions with other system calls is simply too high i think.

>  - chroot the compiler into the right directory

yeah, if it was that easy ;( there're a bunch of auxillary files that
still have to be reachable.

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
 --fake-pcwd=... or similar option.

>  - 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. i.e. my remote machines don't have the
source tree available (NFS mounting it there isn't really an option and
would btw defeat possible future support for ssh in distcc), and user
timj wouldn't be allowed to mkdir in /usr/src (while /usr/src/project
is the location on the devel machine and is writable for him).

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

>
> --
> Martin
>

PS: i'm not subscribed to the distcc mailing, so please Cc: me if you
    mean to reach me.

---
ciaoTJ