[distcc] Re: Distcc & GDB (fix)

[Thomas Walker]

Thank you very much, I'll take a look at the patch and see what I can do...
I certainly realize that Redhat and the GCC guys are very different (but
overlapping) groups.  I just figured it couldn't hurt to try pushing a
little harder in a place that I have access to to see if this behavior
could be fixed.  I would gather that, although Redhat does not have any
direct control over gcc (or any other fsf project) that they do have some
(slight) influence over the bug report/feature request end of things (I've
had moderate success with glibc issues thus far through them).	It does,
afterall, seem ridiculous that the source directory is not picked up in a
place where it is more or less guaranteed to be accurate at the cost of a
few extra bytes in the .i file (which is generally then immediately
discarded...)

Tom.

Alexandre Oliva <oliva at lsd.ic.unicamp.br> wrote:
>
>On May  9, 2003, Thomas Walker <Thomas.Walker at morganstanley.com> wrote:
>
>> Alexandre, you had mentioned that you had, at some point, passed a patch

>> to fix this behaviour (I'm assuming it caused cpp to always include the
>> full path to source in the .i files, which makes sense because cpp is
>> the only part of the compiler that is guarenteed to actually know where
>> they are) but that the preprocessor guys had been reluctant to include
>> it (or admit it as a bug).  Do you happen to still have a copy of this
>> patch lying around?
>
>Here it is.  At some point around the dates in the diff, it even
>worked :-)
>
>
>--------------------------------------------
>Attachment: 
>MIME Part:  2
>This attachment is not viewable so the text 
>is not included in this reply.
>--------------------------------------------
><HR WIDTH=90% SIZE=4><BR>
>
>> I recently brought the issue to the attention of
>> our Enterprise Support rep at Redhat and he seemed to think that he
>> could help with getting the patch pushed through (it helps being a
>> really big client I guess :)
>
>'fraid there's not much the rep can do, other than getting the patch
>included in the GCC that Red Hat ships to you, but in general we try
>to minimize divergence from the FSF-released GCC.
>
>The thing is that the maintainers of the preprocessor in GCC for the
>FSF, none of which are Red Hat associates, don't agree that the
>current behavior is wrong.  And, even if they were Red Hat associates,
>their judgment on whether a patch is appropriate for FSF GCC shouldn't
>be affected by this, since maintainers of FSF projects, while wearing
>their maintainer hats, are working for the FSF, not for whatever
>company happens to employ them.  Even if the maintainer hats happen to
>be red :-) :-)
>
>Of course, anyone may be willing to support a toolchain with a custom
>patch, and your Red Hat rep might end up finding that this could be a
>solution to solve your problem.  But it's far beyond Red Hat's powers
>to force any patch into GCC or any other FSF project, no matter how
>important the feature is for Red Hat's customers.
>
>If you'd like to get me involved in this issue, please send me (in
>private, to aoliva at redhat.com) the enterprise support request number,
>and the e-mail address of your rep, and I'll figure out how to get
>involved.
>
>Thank you,
>
>-- 
>Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
>Red Hat GCC Developer		       aoliva@{redhat.com, gcc.gnu.org}
>CS PhD student at IC-Unicamp	     oliva@{lsd.ic.unicamp.br, gnu.org}
>Free Software Evangelist		 Professional serial bug killer
>



--
NOTICE: If received in error, please destroy and notify sender.  Sender does not waive confidentiality or privilege, and use is prohibited.