This is the mail archive of the
mailing list for the Cygwin project.
cc/c89/c99 as aliases for gcc [was Re: gcc4: cc]
- From: Dave Korn <dave dot korn dot cygwin at googlemail dot com>
- To: cygwin at cygwin dot com
- Date: Sun, 09 Aug 2009 21:19:52 +0100
- Subject: cc/c89/c99 as aliases for gcc [was Re: gcc4: cc]
- References: <49C0467A.email@example.com> <49C07906.firstname.lastname@example.org> <49C07E09.email@example.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
> 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.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple