Relação entre cc1 e gcc?

Estou tentando instalar o Ruby no meu diretório pessoal em um servidor Linux (sem acesso root), o que obviamente requer o uso gcc. A coisa mais próxima que posso encontrar é um diretório com esse nome que (se você for fundo o suficiente) contém 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

O fato de que redirecionamentos CC1 para GCC na Wikipedia parece implicar algo próximo a identidade, no entanto não há nenhuma outra menção de CC1 na página GCC além da nota sobre redirecionamento, e pesquisando não tenha chegado-me qualquer coisa útil, e minhas tentativas para uso cc1em local de gccter falhado.

Qual é exatamente a relação entre eles? E isso me oferece alguma esperança de compilar Ruby nesta máquina?

O GCC possui várias fases para sua compilação e usa diferentes comandos internos para executar cada fase. O C, em particular, é pré-processado com o cpp, depois é compilado no assembly, montado na linguagem de máquina e depois vinculado.

cc1 é o comando interno que pega arquivos de linguagem C pré-processados ​​e os converte em assembly. É a parte real que compila o C. No C ++, há o cc1plus e outros comandos internos para diferentes idiomas.

Há um livro no Wikilivros que explica o processo com fotos .

Infelizmente, o cc1 é um comando interno e apenas uma parte da instalação e, se isso é tudo o que você tem, não poderá compilar coisas.

gccé o nome do conjunto ccé apenas o compilador C desse conjunto.

a palavra cctambém é um nome genérico para qualquer compilador c em sistemas unix, por exemplo, não é raro encontrar uma variável de ambiente chamada CCem um script de construção ou script de configuração e, se você quiser ser pedante, essa variável geralmente aponta para ac compilador que não executa necessariamente a vinculação do seu objeto compilado, geralmente é usado para se referir a um compilador que "apenas" compila. ccfrom gccé, no entanto, capaz de produzir um executável finalizado, portanto, também é possível executar esta etapa final com seu vinculador.

a palavra cc1é frequentemente usada "internamente" ou ao ler os documentos GNU ( exemplo ), também é usada para nomear bibliotecas relacionadas ao gcc com base em qual idioma ou compilador a que pertencem (neste caso, cc1 = pertence ao compilador c).

de fato, se você perguntar gccqual é o significado da palavracc1

gcc -print-prog-name=cc1

ele deve responder com o caminho da biblioteca para o compilador cc; portanto, você está tentando executar algo que é uma biblioteca e não um executável real.

é muito mais simples lembrar-se do CC como compilador c e simplificar tudo. Ignore esse cc1. Você não precisa saber como as coisas funcionam internamente, a menos que queira iniciar uma longa jornada.

Como outros mencionaram, gccusa cc1.

A exata maneira em que cc1e outro sub-programa como cppe ldsão chamados é feito é determinado pelo arquivos de especificação de formato.

O arquivo de especificação atual pode ser visualizado com:

gcc -dumpspecs

A seção relevante parece ser:

*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}

E você pode usar seu próprio arquivo de especificação com:

gcc -specs=<specs-file>

Obviamente, as opções de linha de comando transmitidas ao GCC alteram indiretamente a forma como os subprocessos são chamados. Mas a manipulação de arquivos de especificação oferece maior flexibilidade e permite que você faça coisas que as opções de linha de comando não podem, por exemplo, /programming/7493620/inhibit-default-library-paths-with-gcc

Você pode observar o que está sendo executado facilmente com:

gcc -v hello_world.c |& grep cc1

Saída de amostra:

/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 é o pré-processador e o compilador, cuja entrada é código-fonte C e a saída é código de montagem.

Você pode ver que cc1é um dos comandos invocados (o primeiro, de fato) emitindo (sintaxe dependente da versão):
gcc-8 -v SOMESOURCE.c