cc1とgccの関係？

Linuxサーバー（ルートアクセスなし）のホームディレクトリにRubyをインストールしようとしていますが、もちろんを使用する必要がありgccます。私が見つけることができる最も近いものは、（あなたが十分に深く行くなら）含まれているその名前のディレクトリですcc1：

>: find / -iname gcc 2> /dev/null
/usr/libexec/gcc


>: tree -if /usr/libexec/gcc
/usr/libexec/gcc
/usr/libexec/gcc/x86_64-redhat-linux
/usr/libexec/gcc/x86_64-redhat-linux/4.1.1
/usr/libexec/gcc/x86_64-redhat-linux/4.1.1/cc1
/usr/libexec/gcc/x86_64-redhat-linux/4.1.2 -> 4.1.1

CC1がWikipediaでGCCにリダイレクトするという事実は、身元に近いものを暗示しているように見えますが、リダイレクトに関するメモ以外にGCCページにCC1の言及はなく、グーグルは私に有用なものを何も提供しておらずcc1、gcc失敗した場所。

それらの間の正確な関係は何ですか？そして、このマシンでRubyをコンパイルする希望を与えてくれますか？

GCCにはコンパイルにいくつかのフェーズがあり、各フェーズを実行するために異なる内部コマンドを使用します。特にCは、最初にcppで前処理され、次にアセンブリにコンパイルされ、機械語にアセンブルされ、その後リンクされます。

cc1は、前処理されたC言語ファイルを取得してアセンブリに変換する内部コマンドです。Cをコンパイルするのは実際の部分です。C++の場合、cc1plus、およびさまざまな言語用の他の内部コマンドがあります。

ウィキブックスには、写真でプロセスを説明する本があります。

残念ながら、cc1は内部コマンドであり、インストールの一部にすぎません。それだけで済む場合は、コンパイルできません。

gccスイートの名前は、ccこのスイートの単なるCコンパイラです。

言葉 cc Unixシステム下の特定のcコンパイラの一般名でもあります。たとえばCC、特定のビルドスクリプトまたはconfigureスクリプトで呼び出される環境変数を見つけることは珍しくありません。コンパイルされたオブジェクトのリンクを必ずしも実行するわけではないコンパイラ。通常、「ただ」コンパイルするコンパイラを参照するために使用されます。ただし、ccfrom gccは、完成した実行可能ファイルを出力できるため、この最終ステップをリンカーでも実行できます。

言葉 cc1多くの場合「内部」で使用される、またはGNUドキュメントを読むとき（例）、それらが属する言語またはコンパイラに基づいてgcc関連ライブラリの名前を付けるためにも使用されます（この場合cc1 = cコンパイラに属します）。

gcc言葉の意味は何ですかと尋ねると、事実cc1

gcc -print-prog-name=cc1

ccコンパイラのライブラリのパスで応答する必要があるため、実際の実行可能ファイルではなくライブラリであるものを実行しようとしています。

CCをcコンパイラとして覚えてすべてを単純化し、このcc1をバイパスする方がはるかに簡単です。長い旅を始めたくない限り、内部での動作を知る必要はありません。

他の人が述べたように、gcc使用cc1ます。

正確な方法でこれcc1等の他のサブプログラムcppとldによって決定され実行されると呼ばれているスペックファイル形式。

現在のスペックファイルは次の方法で表示できます。

gcc -dumpspecs

関連するセクションは次のようです：

*cc1_options:
%{pg:%{fomit-frame-pointer:%e-pg and -fomit-frame-pointer are incompatible}} %{!iplugindir*:%{fplugin*:%:find-plugindir()}} %1 %{!Q:-quiet} %{!dumpbase:-dumpbase %B} %{d*} %{m*} %{aux-info*} %{fcompare-debug-second:%:compare-debug-auxbase-opt(%b)}  %{!fcompare-debug-second:%{c|S:%{o*:-auxbase-strip %*}%{!o*:-auxbase %b}}}%{!c:%{!S:-auxbase %b}}  %{g*} %{O*} %{W*&pedantic*} %{w} %{std*&ansi&trigraphs} %{v:-version} %{pg:-p} %{p} %{f*} %{undef} %{Qn:-fno-ident} %{Qy:} %{-help:--help} %{-target-help:--target-help} %{-version:--version} %{-help=*:--help=%*} %{!fsyntax-only:%{S:%W{o*}%{!o*:-o %b.s}}} %{fsyntax-only:-o %j} %{-param*} %{coverage:-fprofile-arcs -ftest-coverage}

そして、あなたはあなた自身のスペックファイルを以下で使用できます：

gcc -specs=<specs-file>

もちろん、GCCに渡されるコマンドラインオプションは、サブプロセスの呼び出し方法を間接的に変更します。ただし、specファイルを操作すると柔軟性が向上し、コマンドラインオプションではできないことを実行できます（例：https : //stackoverflow.com/questions/7493620/inhibit-default-library-paths-with-gcc

実行されているものを簡単に観察できます：

gcc -v hello_world.c |& grep cc1

サンプル出力：

/usr/lib/gcc/x86_64-linux-gnu/4.8/cc1 -quiet -v -imultiarch x86_64-linux-gnu hello_world.c -quiet -dumpbase hello_world.c -mtune=generic -march=x86-64 -auxbase hello_world -version -fstack-protector -Wformat -Wformat-security -o /tmp/ccvcVNAX.s

cc1 プリプロセッサとコンパイラの両方であり、その入力はCソースコードであり、出力はアセンブリコードです。

次cc1のコマンドを発行することで（実際には最初の）コマンドが呼び出されます：
gcc-8 -v SOMESOURCE.c