70

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

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

編集：これまでに受け取った回答のいずれも、GCCが一方の方法で呼び出された場合と他方の方法で呼び出された場合に異なる動作をするかどうかについて決定的な「はい」または「いいえ」を示しませんでした。しかし、その振る舞いをチェックするためにソースに飛び込むために与えられたアイデアは、私をその道へと導きます。私がそこで見つけたものに基づいて、私は今、答えは次のとおりであると信じています。

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

4

11 に答える 11

35

argv[0]にやにや笑いについては、gcc内からどのように使用されているかを追跡しました（ main.c-> top_lev.c-> opts.c-> langhooks.c） 。現在、失敗したときに報告するために何かをargv[0]提供するためだけに使用されているようです。以外のmalloc場合、動作に変化はないようです。argv[0]gcc

于 2009-06-02T15:41:56.207 に答える
15

cc（古いSUS仕様へのリンク）は、システムのコンパイラへのベンダー中立のインターフェイスを意図しているように見えます。レガシーとしてマークされています：

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

POSIXにc99は、の後継であると私が信じていると呼ばれるユーティリティがありc89ます。それは言う

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

私はこれらのさまざまな標準すべてに精通しているわけではありませんが、最近のSUSv3（POSIX：2004）とさらに最近のPOSIX：2008（まだSUS番号がないようです）はユーティリティを指定していないようですもう呼び出されccますが、ユーティリティのみが呼び出されc99ます。ちなみに、私のLinuxシステム（Arch_Linux）にはのマンページが含まれていますが、は含まれてc99いませんがc89、と呼ばれるユーティリティのみが含まれていますccが、も。も含まれていませc89んc99。そこには多くの混乱があります:)

于 2009-06-02T15:07:23.953 に答える
12

私のMacでman gcc：

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

これに基づいて、ccとgccは同じように動作すると思います。

于 2009-06-02T14:55:11.607 に答える
11

今日も同じ疑問があり、自分で見つけようとしました。

$ 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。それらが同じものを印刷する場合、それはそれらがまったく同じであることを意味します。

于 2010-02-28T12:18:06.050 に答える
7

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である可能性を考慮していません。ですから、あなたがあなたの仮定をどこまで取るかに注意してください。

于 2010-12-17T16:25:45.470 に答える
3

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

于 2009-06-02T15:15:48.757 に答える
3

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

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

#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」を使用し、引数として「AAAAAAAAAAAAAAAAAAAAAAAAA」を渡すと、buffer2にオーバーフローしませんが、「cc」でコンパイルした場合はオーバーフローします。これは、「gcc」を使用した場合のメモリ管理のヒントです。おそらくフィールドbuff1とbuff2のメモリセグメントの間にスペースを置くことによって、異なる働きをしますか？

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

于 2015-06-18T17:28:40.333 に答える
2

GCCのドキュメントには、実行可能ファイルの名前がgccではなくccの場合、GCCの動作が異なることを示すものはありません。GNU Fortranコンパイラは、次のようにも述べています。

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

于 2009-06-02T15:18:21.450 に答える
2

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

[元の投稿から引用。]

私のUbuntu14.04での経験に基づくと、これは当てはまりませんでした。

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

gcc -finstrument-functions test.c

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

cc -finstrument-functions test.c

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

于 2014-09-09T18:35:58.363 に答える
1

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

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

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

于 2009-06-02T15:06:00.897 に答える
1

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

于 2016-03-30T14:45:21.850 に答える