Relazione tra cc1 e gcc?

Sto cercando di installare Ruby nella mia directory home su un server Linux (senza accesso root), che ovviamente richiede l'utilizzo gcc. La cosa più vicina che posso trovare è una directory con quel nome che (se vai abbastanza in profondità) 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

Il fatto che CC1 reindirizzi a GCC su Wikipedia sembra implicare qualcosa di simile all'identità, tuttavia non c'è altra menzione di CC1 sulla pagina GCC oltre alla nota sul reindirizzamento e Googling non mi ha procurato nulla di utile e i miei tentativi di utilizzare cc1in luogo del gccfallimento.

Qual è esattamente la relazione tra loro? E mi offre qualche speranza di compilare Ruby su questa macchina?

GCC ha una serie di fasi per la sua compilazione e utilizza diversi comandi interni per eseguire ciascuna fase. C in particolare viene prima preelaborato con cpp, quindi viene compilato in assembly, assemblato in linguaggio macchina e quindi collegato tra loro.

cc1 è il comando interno che accetta i file in linguaggio C preelaborati e li converte in assembly. È la parte effettiva che compila C. Per C ++, c'è cc1plus e altri comandi interni per lingue diverse.

C'è un libro su Wikibooks che spiega il processo con le immagini .

Sfortunatamente, cc1 è un comando interno e solo un pezzo dell'installazione, e se questo è tutto ciò che hai, non sarai in grado di compilare le cose.

gccè il nome della suite ccè solo il compilatore C di questa suite.

la parola ccè anche un nome generico per qualsiasi dato compilatore c in sistemi unix, ad esempio non è raro trovare una variabile d'ambiente chiamata CCin un determinato script di costruzione o configurare uno script e, se si desidera essere pedanti, questa variabile di solito punta a ac compilatore che non esegue necessariamente il collegamento dell'oggetto compilato, di solito viene utilizzato per fare riferimento a un compilatore che "solo" compila. ccda gcc, tuttavia, è in grado di generare un eseguibile finito, quindi è in grado di eseguire anche questo passaggio finale con il suo linker.

la parola cc1è spesso usata "internamente" o quando legge documenti GNU ( esempio ), è anche usata per nominare la libreria relativa a gcc in base alla lingua o al compilatore a cui appartengono (in questo caso cc1 = appartiene al compilatore c).

infatti se chiedi gccqual è il significato della parolacc1

gcc -print-prog-name=cc1

dovrebbe rispondere con il percorso della libreria per il compilatore cc, quindi stai cercando di eseguire qualcosa che è una libreria e non un vero eseguibile.

è molto più semplice ricordare CC come compilatore c e semplificare tutto, bypassare questo cc1, non è necessario sapere come funzionano le cose internamente a meno che non si desideri iniziare un lungo viaggio.

Come altri hanno già detto, gccutilizza cc1.

Il esatto modo in cui cc1e altri sub-programma come cppe ldsono chiamati è fatto è determinato dal file di specifiche di formato.

Il file delle specifiche corrente può essere visualizzato con:

gcc -dumpspecs

La sezione pertinente sembra essere:

*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 puoi usare il tuo file di specifiche con:

gcc -specs=<specs-file>

Naturalmente, le opzioni della riga di comando passate a GCC cambiano indirettamente il modo in cui vengono chiamati i processi secondari. La manipolazione dei file di specifiche offre una maggiore flessibilità e consente di fare cose che le opzioni della riga di comando non possono, ad esempio /programming/7493620/inhibit-default-library-paths-with-gcc

Puoi osservare ciò che viene eseguito facilmente con:

gcc -v hello_world.c |& grep cc1

Uscita campione:

/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 è sia il preprocessore che il compilatore, il cui input è il codice sorgente C e l'output è il codice assembly.

Puoi vedere cc1è uno dei comandi invocati (il primo, infatti) emettendo (la sintassi dipende dalla versione):
gcc-8 -v SOMESOURCE.c