Relación entre cc1 y gcc?

Estoy tratando de instalar Ruby en mi directorio de inicio en un servidor Linux (sin acceso de root), que por supuesto requiere usar gcc. Lo más cercano que puedo encontrar es un directorio con ese nombre que (si profundizas lo suficiente) contiene 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

El hecho de que CC1 redirija a GCC en Wikipedia parece implicar algo cercano a la identidad, sin embargo, no hay otra mención de CC1 en la página de GCC además de la nota sobre la redirección, y Google no me ha dado nada útil, y mis intentos de usar cc1en lugar de gcchaber fallado.

¿Cuál es exactamente la relación entre ellos? ¿Y me ofrece alguna esperanza de compilar Ruby en esta máquina?

GCC tiene una serie de fases para su compilación, y utiliza diferentes comandos internos para realizar cada fase. C en particular se procesa primero con cpp, luego se compila en ensamblaje, se ensambla en lenguaje de máquina y luego se vinculan entre sí.

cc1 es el comando interno que toma archivos de lenguaje C preprocesados ​​y los convierte en ensamblados. Es la parte real que compila C. Para C ++, hay cc1plus y otros comandos internos para diferentes lenguajes.

Hay un libro en Wikilibros que explica el proceso con imágenes .

Desafortunadamente, cc1 es un comando interno y solo una parte de la instalación, y si eso es todo lo que tiene, no podrá compilar cosas.

gcces el nombre de la suite cces solo el compilador de C de esta suite.

la palabra cctambién es un nombre genérico para cualquier compilador de c dado bajo sistemas unix, por ejemplo, no es raro encontrar una variable de entorno llamada CCen un script de construcción dado o configurar script, y si quieres ser pedante, esta variable generalmente apunta a ac compilador que no necesariamente realiza la vinculación de su objeto compilado, generalmente se usa para referirse a un compilador que "simplemente" compila. Sin embargo, ccfrom gcces capaz de generar un ejecutable terminado, por lo que también puede realizar este paso final con su vinculador.

la palabra cc1a menudo se usa "internamente" o cuando se lee documentos de GNU ( ejemplo ), también se usa para nombrar la biblioteca relacionada con gcc según el idioma o el compilador al que pertenecen (en este caso, cc1 = pertenece al compilador c).

de hecho si preguntas gcccuál es el significado de la palabracc1

gcc -print-prog-name=cc1

debería responder con la ruta de la biblioteca para el compilador cc, por lo que está intentando ejecutar algo que sea una biblioteca y no un ejecutable real.

es mucho más simple recordar CC como compilador de c y simplificar todo, omitir este cc1, no necesita saber cómo funcionan las cosas internamente a menos que quiera comenzar un largo viaje.

Como otros mencionaron, los gccusos cc1.

El formato exacto de los archivos de especificaciones determina la forma exacta en que se llama y se llama a cc1otros subprogramas .cppld

El archivo de especificaciones actual se puede ver con:

gcc -dumpspecs

La sección 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}

Y puede usar su propio archivo de especificaciones con:

gcc -specs=<specs-file>

Por supuesto, las opciones de línea de comando pasadas a GCC cambian indirectamente cómo se llaman los subprocesos. Pero manipular archivos de especificaciones le brinda una mayor flexibilidad y le permite hacer cosas que las opciones de línea de comando no pueden, por ejemplo, /programming/7493620/inhibit-default-library-paths-with-gcc

Puede observar lo que se ejecuta fácilmente con:

gcc -v hello_world.c |& grep cc1

Salida de muestra:

/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 es tanto el preprocesador como el compilador, cuya entrada es el código fuente C y la salida es el código ensamblador.

Puede ver cc1uno de los comandos invocados (el primero, de hecho) emitiendo (la sintaxis depende de la versión):
gcc-8 -v SOMESOURCE.c