On Thu, 7 Nov 2002, Martin Pool wrote: > On 7 Nov 2002, Tim Janik <[EMAIL PROTECTED]> 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 _______________________________________________ distcc mailing list [EMAIL PROTECTED] http://lists.samba.org/cgi-bin/mailman/listinfo/distcc
