X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 	tests=AWL,BAYES_00,SPF_PASS
X-Spam-Check-By: sourceware.org
Message-ID: <4A7F2F68.3090307@gmail.com>
Date: Sun, 09 Aug 2009 21:19:52 +0100
From: Dave Korn <dave DOT korn DOT cygwin AT googlemail DOT com>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: cc/c89/c99 as aliases for gcc [was Re: gcc4: cc]
References: <49C0467A DOT 1080404 AT users DOT sourceforge DOT net> <49C07906 DOT 2060504 AT gmail DOT com> <49C07E09 DOT 5070909 AT users DOT sourceforge DOT net>
In-Reply-To: <49C07E09.5070909@users.sourceforge.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

[  Replying to a fairly random post to revive this old thread.  ]

Yaakov (Cygwin/X) wrote:
> Dave Korn wrote:
>>   Ah, thanks for pointing this out.  (The packages are of course broken as far
>> as portability is concerned, as upstream GCC does not anywhere provide a 'cc'
>> executable; it's presence in the gcc-3 package is caused by the build script
>> creating a symlink as a convenience, so it's wrong in general to assume that
>> there "must be" an executable called 'cc' in the PATH.)  I'll add it back into
>> the next release.
> 
> Actually, SUSv2 requires a cc and c89; SUSv3 mentions only a c99.

  It turns out on closer examination that GCC does not in fact conform to the
SUSv2 specifications for cc or c89, or the SUSv3 specification for c99.  All
three of those descriptions include the following text in the description of the
-D option:

> The -D option has lower precedence than the -U option. That is, if name is
> used in both a -U and a -D option, name will be undefined regardless of the
> order of the options.

  GCC's behaviour is to respect the command-line ordering of -D and -U options
 (which means that you can put $(CFLAGS) at the very end of your command-lines
in makefiles, and the user's flags have the option to override existing options
both positively and negatively).

  This makes me think that I should not ship anything by those names that is
merely an alias for gcc.  It would help broken packages that assume the
existence of cc, but break any that assume the semantics of cc.  I'm not sure
which of those two is best.

  It's possible that there might be a command-line switch to implement this
behaviour in 4.5.0, in which case the problem will be moot and I can ship simple
wrapper scripts that pass through the command-line options adding the new switch
as they go, but I'm inclined to /not/ include simple alternatives-based aliases.

    cheers,
      DaveK

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple