Relation entre cc1 et gcc?

J'essaye d'installer Ruby dans mon directory personnel sur un server Linux (sans access root), ce qui nécessite bien sûr d'utiliser gcc . La chose la plus proche que je puisse find est un directory de ce nom qui contient (si vous allez assez profond) contient 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 

Le fait que CC1 redirige vers GCC sur Wikipédia semble impliquer quelque chose de proche de l'identité, mais il n'y a aucune autre mention de CC1 sur la page GCC en plus de la note sur la redirection, et Googling ne m'a rien cc1 utile, et mes tentatives d'utiliser cc1 à la place de gcc ont échoué.

Quelle est exactement la relation entre eux? Et cela me donne-t-il l'espoir de comstackr Ruby sur cette machine?

GCC a un certain nombre de phases à sa compilation, et il utilise différentes commands internes pour faire chaque phase. C en particulier est d'abord prétraité avec cpp, puis compilé en assembleur, assemblé en langage machine, puis lié set.

cc1 est la command interne qui prend les files de langage C prétraités et les convertit en assembly. C'est la partie réelle qui comstack C. Pour C ++, il y a cc1plus, et d'autres commands internes pour différentes langues.

Il y a un livre sur Wikibooks qui explique le process avec des images .

Malheureusement, cc1 est une command interne et une seule partie de l'installation, et si c'est tout ce que vous avez, vous ne pourrez pas comstackr les choses.

gcc est le nom de la suite cc est juste le compilateur C de cette suite.

le mot cc est aussi un nom générique pour un compilateur c donné sous unix, par exemple il n'est pas rare de find une variable d'environnement appelée CC dans un script de construction ou un script de configuration, et si vous voulez être pédant, à un compilateur qui n'effectue pas nécessairement la binding de votre object compilé, il est généralement utilisé pour faire reference à un compilateur qui comstack simplement. cc de gcc est, cependant, capable de sortir un exécutable fini est donc capable d'effectuer cette dernière étape avec son éditeur de liens aussi.

le mot cc1 est souvent utilisé "en interne" ou lors de la lecture de GNU docs ( exemple ), il est également utilisé pour nommer la bibliothèque gcc en fonction de la langue ou du compilateur auquel ils appartiennent (dans ce cas, cc1 = appartient au compilateur c).

en fait si vous requestz à gcc quel est le sens du mot cc1

 gcc -print-prog-name=cc1 

il devrait répondre avec le path de la bibliothèque pour le compilateur cc, donc vous essayez d'exécuter quelque chose qui est une bibliothèque et non un vrai exécutable.

il est beaucoup plus simple de se souvenir de CC comme c compilateur et de tout simplifier, contourner ce cc1, vous n'avez pas besoin de savoir comment les choses fonctionnent en interne, sauf si vous voulez commencer un long voyage.

Comme d'autres l'ont mentionné, gcc utilise cc1 .

La façon exacte dont cc1 et les autres sous-programmes tels que cpp et ld sont appelés est déterminée par le format des files de spécifications .

Le file de spécifications actuel peut être visualisé avec:

 gcc -dumpspecs 

La section pertinente semble être:

 *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-ssortingp %*}%{!o*:-auxbase %b}}}%{!c:%{!S:-auxbase %b}} %{g*} %{O*} %{W*&pedantic*} %{w} %{std*&ansi&sortinggraphs} %{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 %bs}}} %{fsyntax-only:-o %j} %{-param*} %{coverage:-fprofile-arcs -ftest-coverage} 

Et vous pouvez utiliser votre propre file de spécifications avec:

 gcc -specs=<specs-file> 

Bien sûr, les options de command line transmises à GCC changent indirectement la façon dont les sous-process sont appelés. Mais la manipulation des files de spécification vous donne une plus grande flexibilité et vous permet de faire des choses que les options de command line ne peuvent pas, par exemple https://stackoverflow.com/questions/7493620/inhibit-default-library-paths-with-gcc

Vous pouvez observer ce qui se passe facilement avec:

 gcc -v hello_world.c |& grep cc1 

Exemple de sortie:

 /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