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