From: khan AT xraylith DOT wisc DOT edu (Mumit Khan)
Subject: Re: [bug] gcc -print-prog-name
12 Nov 1998 15:49:32 -0800
Message-ID: <9811122326.AB20701.cygnus.cygwin32.developers@modi.xraylith.wisc.edu>

------- Blind-Carbon-Copy

To: earnie_boyd AT yahoo DOT com
cc: cygwin users <gnu-win32 AT cygnus DOT com>
Subject: Re: [bug] gcc -print-prog-name 
In-reply-to: Your message of "Wed, 11 Nov 1998 12:59:15 PST."
             <19981111205915 DOT 12757 DOT rocketmail AT send1b DOT yahoomail DOT com> 
Date: Thu, 12 Nov 1998 17:26:48 -0600
From: Mumit Khan <khan AT modi DOT xraylith DOT wisc DOT edu>

Earnie Boyd <earnie_boyd AT yahoo DOT com> writes:
> gcc -print-prog-name, gcc -print-file-name, etc. returns the win32
> path instead of the cygwin path.  This breaks all kinds of configure
> scripts.

This is of course not a bug, but rather a feature ;-)

I'm personally against this mis-feature, and would very much like to junk 
the change that makes this happen. Since the chances of cygwin gcc
exec'ing a non-cygwin program** is rather slim at this point, I see
no reason for this.

Few things that this feature breaks:
  
  1. Auto-generated dependency info in Makefiles, which confuses the hell
     out of make with ':' and '\'. This is a serious problem in my book.
  1. Anything that checks for GCC subprograms using -print-prog-name=xxx
     or checks for various other files using -print-file-name=xxx. An
     example of this is where configure scripts check for libg2c vs 
     libf2c.
       
       libg2c=`gcc -print-file-name=libg2c`
       # use $libg2c to do the right thing.

If you strongly as to why this mis-feature should continue to exist,
please speak up (those against, don't bother -- I already know all the
bad things ;-). I'd rather not revert to the old behaviour and find out 
that it messes up half of cygwin ...

Regards,
Mumit

** The only non-cygwin program the GCC can potentially call is the
Platform SDK "link.exe", but I highly suspect if that will ever happen.


------- End of Blind-Carbon-Copy