web-dev-qa-db-ja.com

GCCを「cc」と「gcc」として呼び出す

ほとんどのGNU/Linuxシステムでは、コマンドラインから「cc」という名前でGCCを呼び出すことができます（「gcc」ではなく）。ある方法で呼び出されたときと他の方法で呼び出されたときのGCCの動作に違いはありますか？

たとえば、「gcc」ではなく「g ++」という名前でGCCを呼び出すと、GCCの動作が異なることがわかります（.cファイルをC++ソースとして扱い、C++標準ライブラリにリンクします）。 「gcc」と「cc」の動作に同様の違いはありますか？

編集：これまでに受け取った回答では、GCCが動作するかどうかについてdefinitive「yes」または「no」を返しませんでした。一方と他方で呼び出された場合は異なります。しかし、その動作を確認するためにソースに飛び込むというアイデアは、私をその道に導きました。そこで見つけたものに基づいて、私は答えが次のとおりであると信じています。

いいえ。GCCは、 "gcc"または "cc"を介して呼び出されるかどうかにかかわらず、同じように動作します。

clinuxgcccompiler-constructiongnu
67
Dan Moulding

笑顔のために、gcc内からargv[0]がどのように使用されるかをトレースしました（ main.c -> top_lev.c-> opts.c-> langhooks.c）そしてargv[0]は現在、mallocが失敗した場合に報告する何かを与えること以外の目的には使用されていないようです。 argv[0]がgcc以外の場合、動作の変更はないようです。

35
plinth

cc （いくつかの古いSUS仕様へのリンク）は、システムのコンパイラへのベンダー中立インターフェイスであることが意図されているようです。レガシーとしてマーク：

C89ユーティリティーはISO C標準へのインターフェースを提供しますが、ccユーティリティーはC言語の不特定の方言を受け入れます。これは、標準C、共通使用C、またはその他のバリアントの場合があります。ポータブルCプログラムは、ISO C標準に準拠するように作成し、c89でコンパイルする必要があります。

POSIXには c99 というユーティリティがあり、これはc89の後継だと思います。それは言う

C99ユーティリティは、ISO POSIX-2：1993標準で最初に導入されたc89ユーティリティに基づいています。 c89からの変更には、新しいヘッダーとオプションに対応するための標準ライブラリセクションの内容の変更が含まれます。たとえば、-l rtオペランドに追加し、トレース機能用に-l traceオペランドを追加しました。

私はこれらのさまざまな標準すべてに精通しているわけではありませんが、最近のSUSv3（ POSIX：2004 ）およびさらに最近の POSIX：2008 （doesn ' tはSUS number）を持っているようです。ccというユーティリティはもう指定せず、c99というユーティリティのみを指定します。ちなみに、私のLinuxシステム（ Arch_Linux ）にはc99のマンページが含まれますが、c89は含まれませんが、ccと呼ばれるユーティリティのみが含まれますが、c89もc99も含まれません。

14
Johannes Schaub - litb

私のMacではman gcc：

GCCのAppleバージョンでは、ccとgccの両方は、実際にはgcc-versionのような名前のコンパイラへのシンボリックリンクです。同様に、c ++とg ++は、g ++-versionなどの名前のコンパイラへのリンクです。

それに基づいて、ccとgccは同じように動作すると仮定します。

12
stefanB

今日も同じ疑問を抱いていたので、自分で見つけようとしました。

$ which cc
 /usr/bin/ccc

$file /usr/bin/cc
 /usr/bin/cc: symbolic link to '/etc/alternatives/cc'

$file /etc/alternatives/cc
 /etc/alternatives/cc: symbolic link to '/usr/bin/gcc'

$which gcc
 /usr/bin/gcc

したがって、基本的にccはgccを指します。

cc -vおよびgcc -vを使用して確認することもできます。同じものを印刷する場合、それらはまったく同じであることを意味します。

8
N 1.1

Gccがargv [0]の値とは無関係に同じ動作をする場合でも、どのコンパイラとして指定するかに関係なく、すべてのソフトウェアが同じ動作をするわけではありません。

RHEL 5.5（gcc 4.1.2）でzlib 1.2.5をビルドする場合：

$ md5sum $(which cc)
69a67d3029b8ad50d41abab8d778e799  /usr/bin/cc
$ md5sum $(which gcc)
69a67d3029b8ad50d41abab8d778e799  /usr/bin/gcc

だが：

$ CC=$(which cc) ./configure
Checking for shared library support...
Tested /usr/bin/cc -w -c -O ztest20557.c
Tested cc -shared -O -o ztest20557.so ztest20557.o
/usr/bin/ld: ztest20557.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
ztest20557.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
No shared library support; try without defining CC and CFLAGS
Building static library libz.a version 1.2.5 with /usr/bin/cc.
Checking for off64_t... Yes.
Checking for fseeko... Yes.
Checking for unistd.h... Yes.
Checking whether to use vs[n]printf() or s[n]printf()... using vs[n]printf().
Checking for vsnprintf() in stdio.h... Yes.
Checking for return value of vsnprintf()... Yes.

そして：

$ CC=$(which gcc) ./configure
Checking for shared library support...
Building shared library libz.so.1.2.5 with /usr/bin/gcc.
Checking for off64_t... Yes.
Checking for fseeko... Yes.
Checking for unistd.h... Yes.
Checking whether to use vs[n]printf() or s[n]printf()... using vs[n]printf().
Checking for vsnprintf() in stdio.h... Yes.
Checking for return value of vsnprintf()... Yes.
Checking for attribute(visibility) support... Yes.

Configureスクリプトは、Linuxシステム上のccがgccになる可能性を考慮しません。だから、あなたがあなたの仮定をどこまでとるかに注意してください。

7
ednos

ccは、コンパイラを呼び出すUNIXの単なる方法であり、すべてのUnicesで機能します。

3
ismail

このスレッドは古いかもしれませんが、何かを追加したいと思います（おそらく誰かがそれを見つけるでしょう）。

このプログラムをコンパイルした場合

#include <stdio.h>
#include <stdlib.h>

void
myFunction(char *args)
{
   char buff1[12];
   char buff2[4] = "ABC";

   strcpy(buff1,args);

   printf("Inhalt Buffer2: %s",buff2);

}

int main(int argc, char *argv[])
{

   if(argc > 1)
   {
      myFunction(argv[1]);
   }
   else
      printf("no arguments sir daimler benz");

   getchar();

   return 0;
}

"gcc"を使用し、引数として "AAAAAAAAAAAAAAAAAAAAAAAAAAA"を渡した場合、buffer2にオーバーフローしませんが、 "cc"でコンパイルした場合はそうなります。フィールドbuff1とbuff2のメモリセグメントの間にスペースを入れるなどして、異なる動作をしますか？

もっと経験のある人は、ここで暗闇に光を当てることができます。

3
clockw0rk

GCCのドキュメントには、GCCの実行可能ファイル名がgccではなくcc。 GNU Fortranコンパイラー偶数 メンション） ：

Gccコマンドのバージョン（システムのccコマンドとしてインストールされる場合もあります）

2
lothar

「いいえ。GCCは、「gcc」または「cc」のどちらから呼び出されても同じように動作します。」

[元の投稿から引用。]

Ubuntu 14.04での経験に基づいて、これはそうではありませんでした。

次を使用してプログラムをコンパイルするとき：

gcc -finstrument-functions test.c

コードの動作に変更はありません。しかし、私が使用してコンパイルするとき

cc -finstrument-functions test.c

動作が異なります。 （どちらの場合も、 ここ で記述されたコードに適切な変更を組み込み、-finstrument-functionsが機能するようにしました）。

2
plafratt

これがUNIXから来ていることを考えると、「cc」は一般名で、「gcc」は実際のコンパイラーだと思います。つまり、「gcc」は「cc」を提供するため、「cc」を探すプログラムは「cc」を見つけて使用します。これは、実際に使用されているコンパイラをまったく知らないものです。

また、UNIXプログラムはそれらを呼び出すために使用される実際の名前を知らない必要があります（Windowsデスクトップのショートカットを考えてください-ショートカットの名前を確認することは意味がありません）。 「cc」が「gcc」へのリンクの場合も同じです。

もちろん、「cc」はシンボリックリンクではなく、gccを呼び出すシェルスクリプトではありません。

1
Alan Plum

私のOS（Ubuntu 14.04）では、ccはタブ補完を許可しませんが、gccはタブ補完を許可します。

1
abcoep