On 09/08/2009 15:19, Dave Korn wrote:
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.
I
[ 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 p
Yaakov (Cygwin/X) wrote:
Are there supposed to be similar names for the ISO C++
standards (c++98 and c++0x)?
My guess would be "no"; at least, there isn't anything with near the
penetration of 'cc', given that I can name about a half dozen c++
compiler names off the top of my head.
--
Matth
Yaakov (Cygwin/X) wrote:
> AFAIK there is no reason for a cc *script*
Good point!
> As for c89/c99, +1 on the script idea; separate versions are definitely
> not necessary. Are there supposed to be similar names for the ISO C++
> standards (c++98 and c++0x)?
Would be trivial to add on top
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dave Korn wrote:
> Perhaps the nice thing to would be supply an auxiliary (optional) package
> full of alternative-name helper shell scripts like these. (Apropos of
> nothing, I'll point out that SUS may demand cc, c89 and/or c99, but says
> nothi
Tim Prince wrote:
> Yaakov (Cygwin/X) wrote:
>
>> While you're at it, if you have a chance, I think a f95 would be helpful
>> as well.
>>
> but some of us may prefer to leave it to the operator to create an alias
> or symlink, which otherwise will increase the number of conflicts which
> arise whe
Yaakov (Cygwin/X) wrote:
>
> While you're at it, if you have a chance, I think a f95 would be helpful
> as well.
>
but some of us may prefer to leave it to the operator to create an alias
or symlink, which otherwise will increase the number of conflicts which
arise when we use cygwin as a develo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eric Blake wrote:
> According to Yaakov (Cygwin/X) on 3/17/2009 10:52 PM:
>> 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 pro
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Yaakov (Cygwin/X) on 3/17/2009 10:52 PM:
> 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'
>> executabl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
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
Yaakov (Cygwin/X) wrote:
> gcc4 does not provide cc-4, nor does the alternatives script provide cc.
> It probably goes without saying that this breaks some (obviously
> non-autotoolized) packages that assume cc's presence.
Ah, thanks for pointing this out. (The packages are of course broken a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dave,
gcc4 does not provide cc-4, nor does the alternatives script provide cc.
It probably goes without saying that this breaks some (obviously
non-autotoolized) packages that assume cc's presence.
Yaakov
Cygwin/X
-BEGIN PGP SIGNATURE-
Ve
13 matches
Mail list logo
