in Breve: Questa guida spiega come installare un programma dal codice sorgente di Linux, e come rimuovere il software installato dal codice sorgente.

Uno dei più grandi punti di forza della vostra distribuzione Linux è il suo gestore di pacchetti e il repository software associato. Con loro, hai tutti gli strumenti e le risorse necessarie per scaricare e installare nuovo software sul tuo computer in modo completamente automatizzato.

Ma nonostante tutti i loro sforzi, i manutentori dei pacchetti non possono gestire tutti i casi d’uso. Né possono confezionare tutto il software disponibile là fuori. Quindi ci sono ancora situazioni in cui dovrai compilare e installare un nuovo software da solo. Per quanto mi riguarda, il motivo più comune, di gran lunga, che devo compilare alcuni software è quando ho bisogno di eseguire una versione molto specifica, o modificare il codice sorgente usando alcune opzioni di compilazione fantasiose.

Se le tue esigenze appartengono a quest’ultima categoria, è probabile che tu sappia già cosa fare. Ma, per la stragrande maggioranza degli utenti Linux, compilare e installare software dal codice sorgente per la prima volta potrebbe sembrare una cerimonia di iniziazione: un po ‘ spaventosa; ma con la promessa di entrare in un nuovo mondo di possibilità e un posto di prestigio in una comunità privilegiata.

A. Installazione di software dal codice sorgente in Linux

E questo è esattamente quello che faremo qui. Ai fini di questo articolo, diciamo che ho bisogno di installare NodeJS 8.1.1 sul mio sistema. Quella versione esattamente. Una versione che non è disponibile dal repository Debian:

sh$ apt-cache madison nodejs | grep amd64 nodejs | 6.11.1~dfsg-1 | http://deb.debian.org/debian experimental/main amd64 Packages nodejs | 4.8.2~dfsg-1 | http://ftp.fr.debian.org/debian stretch/main amd64 Packages nodejs | 4.8.2~dfsg-1~bpo8+1 | http://ftp.fr.debian.org/debian jessie-backports/main amd64 Packages nodejs | 0.10.29~dfsg-2 | http://ftp.fr.debian.org/debian jessie/main amd64 Packages nodejs | 0.10.29~dfsg-1~bpo70+1 | http://ftp.fr.debian.org/debian wheezy-backports/main amd64 Packages

Ora, installare NodeJS su Ubuntu o Debian è piuttosto semplice se lo si fa con il gestore dei pacchetti. Ma facciamolo tramite il codice sorgente.

Passo 1: Ottenere il codice sorgente da GitHub

Come molti progetti open-source, le fonti di NodeJS possono essere trovate su GitHub:https://github.com/nodejs/node

Quindi, andiamo direttamente lì.

Se non si ha familiarità con GitHub, git o qualsiasi altro sistema di controllo di versione vale la pena di menzionare il repository contiene la sorgente di corrente per il software, così come una storia di tutte le modifiche apportate nel corso degli anni per il software. Alla fine fino alla prima riga scritta per quel progetto. Per gli sviluppatori, mantenere quella storia ha molti vantaggi. Per noi oggi, il principale è che saremo in grado di ottenere le fonti da per il progetto come erano in un dato momento. Più precisamente, sarò in grado di ottenere le fonti come erano quando è stata rilasciata la versione 8.1.1 che voglio. Anche se ci sono state molte modifiche da allora.

Su GitHub, è possibile utilizzare il pulsante “branch” per navigare tra le diverse versioni del software. “Branch “e” tag ” sono concetti in qualche modo correlati in Git. Fondamentalmente, gli sviluppatori creano “branch” e” tag ” per tenere traccia di eventi importanti nella cronologia del progetto, come quando iniziano a lavorare su una nuova funzionalità o quando pubblicano una versione. Non voglio entrare nei dettagli qui, tutto quello che dovete sapere è che io sto cercando la versione tagged “v8.1.1”

Dopo aver scelto il “v8.1.1 ” tag, la pagina viene aggiornata, la modifica più ovvia è che il tag ora appare come parte dell’URL. Inoltre, noterai che anche la data di modifica del file è diversa. L’albero dei sorgenti che stai vedendo è quello che esisteva al momento della creazione del tag v8.1. 1. In un certo senso, puoi pensare a uno strumento di controllo della versione come git come una macchina da viaggio nel tempo, che ti consente di andare avanti e indietro nella cronologia di un progetto.

A questo punto, possiamo scaricare i sorgenti di NodeJS 8.1.1. Da non perdere il grande pulsante blu che suggerisce di scaricare l’archivio ZIP del progetto. Per quanto mi riguarda, scaricherò ed estrarrò lo ZIP dalla riga di comando per motivi di spiegazione. Ma se preferisci usare uno strumento GUI, non esitare a farlo invece:

wget https://github.com/nodejs/node/archive/v8.1.1.zipunzip v8.1.1.zipcd node-8.1.1/

Scaricare l’archivio ZIP funziona alla grande. Ma se vuoi farlo “come un professionista”, suggerirei di usare direttamente lo strumento git per scaricare i sorgenti. Non è affatto complicato— e sarà un bel primo contatto con uno strumento che incontrerai spesso:

# first ensure git is installed on your systemsh$ sudo apt-get install git# Make a shallow clone the NodeJS repository at v8.1.1sh$ git clone --depth 1 \ --branch v8.1.1 \ https://github.com/nodejs/nodesh$ cd node/

A proposito, se hai un problema, considera la prima parte di questo articolo come introduzione generale. In seguito ho spiegazioni più dettagliate per le distribuzioni basate su Debian e RedHat al fine di aiutarti a risolvere i problemi più comuni.

Comunque, ogni volta che hai scaricato il sorgente utilizzando git o come un archivio ZIP, si dovrebbe ora avere esattamente la stessa origine i file nella directory corrente:

sh$ lsandroid-configure BUILDING.md common.gypi doc Makefile srcAUTHORS CHANGELOG.md configure GOVERNANCE.md node.gyp testbenchmark CODE_OF_CONDUCT.md CONTRIBUTING.md lib node.gypi toolsBSDmakefile COLLABORATOR_GUIDE.md deps LICENSE README.md vcbuild.bat

Passo 2: descrizione del Sistema di generazione del programma

solitamente parliamo di “compilazione di fonti”, ma la compilazione è solo una delle fasi necessarie alla produzione di un software di lavoro dalla sorgente. Un sistema di compilazione è un insieme di strumenti e pratiche utilizzate per automatizzare e articolare queste diverse attività al fine di costruire interamente il software semplicemente emettendo pochi comandi.

Se il concetto è semplice, la realtà è un po ‘ più complicata. Perché diversi progetti o linguaggio di programmazione possono avere requisiti diversi. O a causa dei gusti del programmatore. O le piattaforme supportate. O per ragioni storiche. O or o.. c’è una lista quasi infinita di motivi per scegliere o creare un altro sistema di compilazione. Tutto questo per dire che ci sono molte soluzioni diverse utilizzate là fuori.

NodeJS utilizza un sistema di compilazione in stile GNU, è una scelta popolare nella comunità open source e ancora una volta, un buon modo per iniziare il tuo viaggio.

Scrivere e sintonizzare un sistema di compilazione è un compito piuttosto complesso, ma per l ‘ “utente finale”, i sistemi di compilazione in stile GNU facilitano il compito utilizzando due strumenti:configure emake.

Il fileconfigure è uno script specifico del progetto che controllerà la configurazione del sistema di destinazione e le funzionalità disponibili per garantire che il progetto possa essere costruito, affrontando infine le specificità della piattaforma corrente.

Una parte importante di un tipicoconfigure lavoro è quello di costruire ilMakefile. Questo è il file contenente le istruzioni necessarie per costruire efficacemente il progetto.

Lo strumento make, d’altra parte, è uno strumento POSIX disponibile su qualsiasi sistema Unix-like. Leggerà il Makefile specifico del progetto ed eseguirà le operazioni necessarie per creare e installare il programma.

Ma, come sempre nel mondo Linux, hai ancora una certa indulgenza nel personalizzare la build in base alle tue esigenze specifiche.

./configure --help

Il comandoconfigure -help mostrerà tutte le opzioni di configurazione disponibili. Ancora una volta, questo è molto specifico per il progetto. E per essere onesti, a volte è necessario scavare nel progetto prima di comprendere appieno il significato di ogni opzione di configurazione.

Ma c’è almeno un’opzione GNU Autotools standard che devi conoscere: l’opzione --prefix. Questo ha a che fare con la gerarchia del file system e il luogo in cui verrà installato il software.

Punto 3: Il FHS

La gerarchia del file system Linux su una distribuzione tipica per lo più conformi al Filesystem Hierarchy Standard (FHS)

Che standard spiega lo scopo delle varie directory del sistema:/usr/tmp/var e così via.

Quando si utilizzano gli Autotools GNU— e la maggior parte degli altri sistemi di compilazione— il percorso di installazione predefinito per il nuovo software sarà/usr/local. Quale è una buona scelta in quanto secondo FSH “La gerarchia / usr / local è utilizzata dall’amministratore di sistema quando si installa il software localmente? Deve essere sicuro di essere sovrascritto quando il software di sistema viene aggiornato. Può essere utilizzato per programmi e dati condivisibili tra un gruppo di host, ma non trovati in /usr.”

/usr/local gerarchia, in qualche modo, replica la directory principale, e troverete /usr/local/bin per i programmi eseguibili, /usr/local/lib per le librerie, /usr/local/share per l’architettura indipendente di file e così via.

L’unico problema quando si utilizza l’albero /usr/local per l’installazione del software personalizzato è che i file per tutto il software verranno mescolati lì. In particolare, dopo aver installato un paio di software, sarà difficile tenere traccia di quale file esattamente di /usr/local/bin e /usr/local/lib appartiene a quale software. Ciò non causerà alcun problema al sistema. Dopo tutto, /usr/bin è quasi lo stesso casino. Ma questo diventerà un problema il giorno in cui vorrai rimuovere un software installato manualmente.

Per risolvere questo problema, di solito preferisco installare software personalizzato nel sotto-albero /opt. Ancora una volta, per citare il FHS:

_” / opt è riservato per l’installazione di pacchetti software applicativi aggiuntivi.

Un pacchetto per essere installato in /opt deve individuare i file statici in una partizione separata per /opt/<pacchetto> o /opt/<provider> albero di directory, dove <pacchetto> è un nome che descrive il pacchetto software e <provider> è il fornitore di LANANA nome registrato.”_

Quindi creeremo una sottodirectory di/opt specificamente per la nostra installazione NodeJS personalizzata. E se un giorno voglio rimuovere quel software, dovrò semplicemente rimuovere quella directory:

sh$ sudo mkdir /opt/node-v8.1.1sh$ sudo ln -sT node-v8.1.1 /opt/node# What is the purpose of the symbolic link above?# Read the article till the end--then try to answer that# question in the comment section!sh$ ./configure --prefix=/opt/node-v8.1.1sh$ make -j9 && echo ok# -j9 means run up to 9 parallel tasks to build the software.# As a rule of thumb, use -j(N+1) where N is the number of cores# of your system. That will maximize the CPU usage (one task per# CPU thread/core + a provision of one extra task when a process# is blocked by an I/O operation.

Tutto tranne “ok” dopo che il comandomake è stato completato significherebbe che c’è stato un errore durante il processo di compilazione. Poiché abbiamo eseguito una build parallela a causa dell’opzione-j, non è sempre facile recuperare il messaggio di errore dato il grande volume di output prodotto dal sistema di compilazione.

Nel caso di un problema, basta riavviare make, ma senza l’opzione -j questa volta. E l’errore dovrebbe apparire verso la fine dell’uscita:

sh$ make

Infine, una volta che la compilazione è andata alla fine, è possibile installare il software per la sua posizione eseguendo il comando:

sh$ sudo make install

E prova:

sh$ /opt/node/bin/node --versionv8.1.1

B. Che se le cose vanno male durante l’installazione da codice sorgente?

Quello che ho spiegato sopra è principalmente quello che puoi vedere nella pagina “build instruction” di un progetto ben documentato. Ma dato questo obiettivo articolo è quello di consentire di compilare il primo software da fonti, potrebbe vale la pena prendere il tempo per indagare su alcuni problemi comuni. Quindi, farò di nuovo l’intera procedura, ma questa volta da un sistema Debian 9.0 e CentOS 7.0 fresco e minimale in modo da poter vedere gli errori che ho riscontrato e come li ho risolti.

Da Debian 9.0 “Stretch”

:~$ git clone --depth 1 \ --branch v8.1.1 \ https://github.com/nodejs/node-bash: git: command not found

Questo problema è abbastanza facile da diagnosticare e risolvere. Basta installare il pacchettogit:

:~$ sudo apt-get install git

:~$ git clone --depth 1 \ --branch v8.1.1 \ https://github.com/nodejs/node && echo okok

:~/node$ sudo mkdir /opt/node-v8.1.1:~/node$ sudo ln -sT node-v8.1.1 /opt/node

Nessun problema qui.

:~/node$ ./configure --prefix=/opt/node-v8.1.1/WARNING: failed to autodetect C++ compiler version (CXX=g++)WARNING: failed to autodetect C compiler version (CC=gcc)Node.js configure error: No acceptable C compiler found! Please make sure you have a C compiler installed on your system and/or consider adjusting the CC environment variable if you installed it in a non-standard prefix.

Ovviamente, per compilare un progetto, è necessario un compilatore. NodeJS essendo scritto utilizzando il linguaggio C++, abbiamo bisogno di un compilatore C++. Qui installerò ‘ g++’, il compilatore GNU C++ per questo scopo:

:~/node$ sudo apt-get install g++:~/node$ ./configure --prefix=/opt/node-v8.1.1/ && echo okok

:~/node$ make -j9 && echo ok-bash: make: command not found

Un altro strumento mancante. Stessi sintomi. Stessa soluzione:

:~/node$ sudo apt-get install make:~/node$ make -j9 && echo okok

:~/node$ sudo make install:~/node$ /opt/node/bin/node --versionv8.1.1

Successo!

Si prega di notare: Ho installato i vari strumenti uno per uno per mostrare come diagnosticare i problemi di compilazione e per mostrarti la soluzione tipica per risolvere questi problemi. Ma se cerchi maggiori informazioni sull’argomento o leggi altri tutorial, scoprirai che la maggior parte delle distribuzioni ha “meta-pacchetti” che fungono da ombrello per installare alcuni o tutti gli strumenti tipici utilizzati per la compilazione di un software. Sui sistemi basati su Debian, probabilmente incontrerete il pacchetto build-essentials per questo scopo. E sulle distribuzioni basate su Red-Hat, quello sarà il gruppo “Strumenti di sviluppo”.

Da CentOS 7.0

 ~]$ git clone --depth 1 \ --branch v8.1.1 \ https://github.com/nodejs/node-bash: git: command not found

Comando non trovato? Basta installarlo utilizzando il yum gestore pacchetti:

 ~]$ sudo yum install git

 ~]$ git clone --depth 1 \ --branch v8.1.1 \ https://github.com/nodejs/node && echo okok

 ~]$ sudo mkdir /opt/node-v8.1.1 ~]$ sudo ln -sT node-v8.1.1 /opt/node

 ~]$ cd node node]$ ./configure --prefix=/opt/node-v8.1.1/WARNING: failed to autodetect C++ compiler version (CXX=g++)WARNING: failed to autodetect C compiler version (CC=gcc)Node.js configure error: No acceptable C compiler found! Please make sure you have a C compiler installed on your system and/or consider adjusting the CC environment variable if you installed it in a non-standard prefix.

Si lo immagino: NodeJS è scritto utilizzando il linguaggio C++, ma il mio sistema manca il compilatore corrispondenti. Yum in soccorso. Poiché non sono un normale utente CentOS, in realtà ho dovuto cercare su Internet il nome esatto del pacchetto contenente il compilatore g++. Mi porta a quella pagina: https://superuser.com/questions/590808/yum-install-gcc-g-doesnt-work-anymore-in-centos-6-4

 node]$ sudo yum install gcc-c++ node]$ ./configure --prefix=/opt/node-v8.1.1/ && echo okok

 node]$ make -j9 && echo okok

 node]$ sudo make install && echo okok

 node]$ /opt/node/bin/node --versionv8.1.1

il Successo. Ancora.

C. Apportare modifiche al software installato dal codice sorgente

È possibile installare il software dal sorgente perché è necessaria una versione molto specifica non disponibile nel repository di distribuzione, o perché si desidera modificare il programma per correggere un bug o aggiungere una funzionalità. Dopo tutto, open-source è tutto di apportare modifiche. Quindi, colgo l’occasione per darvi un assaggio del potere che avete a portata di mano, ora che siete in grado di compilare il proprio software.

Qui, faremo una piccola modifica alle fonti di NodeJS. E vedremo se il nostro cambiamento sarà incorporato nella versione compilata del software:

Apri il filenode/src/node.cc nel tuo editor di testo preferito (vim, nano, gedit,…). E prova a localizzare quel frammento di codice:

 if (debug_options.ParseOption(argv, arg)) { // Done, consumed by DebugOptions::ParseOption(). } else if (strcmp(arg, "--version") == 0 || strcmp(arg, "-v") == 0) { printf("%s\n", NODE_VERSION); exit(0); } else if (strcmp(arg, "--help") == 0 || strcmp(arg, "-h") == 0) { PrintHelp(); exit(0); }

È intorno alla riga 3830 del file. Quindi modificare la riga contenente printf in modo che corrisponda a quella:

 printf("%s (compiled by myself)\n", NODE_VERSION);

Quindi torna al tuo terminale. Prima di andare oltre— e per darti un po ‘ più di comprensione del potere dietro git— puoi controllare se hai modificato il file giusto:

diff --git a/src/node.cc b/src/node.ccindex bbce1022..a5618b57 100644--- a/src/node.cc+++ b/src/node.cc@@ -3828,7 +3828,7 @@ static void ParseArgs(int* argc, if (debug_options.ParseOption(argv, arg)) { // Done, consumed by DebugOptions::ParseOption(). } else if (strcmp(arg, "--version") == 0 || strcmp(arg, "-v") == 0) {- printf("%s\n", NODE_VERSION);+ printf("%s (compiled by myself)\n", NODE_VERSION); exit(0); } else if (strcmp(arg, "--help") == 0 || strcmp(arg, "-h") == 0) { PrintHelp();

Dovresti vedere un “-” (segno meno) prima della linea come era prima di cambiarla. E un ” + ” (segno più) prima della riga dopo le modifiche.

È ora di ricompilare e reinstallare il software:

make -j9 && sudo make install && echo okok

Questa volta, l’unica ragione per cui potrebbe fallire è che hai fatto un errore di battitura mentre cambiavi il codice. In questo caso, riapri il filenode/src/node.cc nel tuo editor di testo e risolvi l’errore.

Una volta che sei riuscito a compilare e installare la nuova versione di NodeJS modificata, sarai in grado di verificare se le tue modifiche sono state effettivamente incorporate nel software:

:~/node$ /opt/node/bin/node --versionv8.1.1 (compiled by myself)

Congratulazioni! Hai fatto la tua prima modifica a un programma open-source!

D. Lascia che la shell localizzi il nostro software di build personalizzato

Potresti aver notato che ho sempre lanciato il mio software NodeJS appena compilato specificando il percorso assoluto del file binario.

/opt/node/bin/node

Funziona. Ma questo è fastidioso, per non dire altro. Ci sono in realtà due modi comuni per risolvere questo problema.

Ci sono in realtà due modi comuni per risolvere il fastidioso problema di specificare il percorso assoluto dei file binari,
ma per capirli devi prima sapere che la tua shell individua i file eseguibili cercandoli solo nelle directory specificate dalla variabile d’ambiente PATH.

:~/node$ echo $PATH/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

Qui, su che sistema Debian, se non si specifica in modo esplicito qualsiasi directory, come parte di un nome di comando, la shell cerca prima di tutto i programmi eseguibili nel /usr/local/bin, quindi se non trovate in /usr/bin quindi se non trovate in /bin quindi se non trovate in /usr/local/games quindi se non trovate in /usr/games, quindi se non trovate … la shell di segnalare un errore “comando non trovato”.

Dato questo, abbiamo due modi per rendere un comando accessibile alla shell: aggiungendolo a una delle directory PATH già configurate. Oppure aggiungendo la directory contenente il nostro file eseguibile al PATH.

l’Aggiunta di un link da /usr/local/bin

copiare il nodo binario eseguibile da /opt/node/bin/usr/local/bin sarebbe una cattiva idea, dato che, così facendo, l’eseguibile del programma, non sarebbe più stato in grado di individuare gli altri componenti necessari appartenenti a /opt/node/ (è una pratica comune, per il software per individuare i file di risorse relative alla propria posizione).

Quindi, il modo tradizionale di farlo è usare un collegamento simbolico:

:~/node$ sudo ln -sT /opt/node/bin/node /usr/local/bin/node:~/node$ which -a node || echo not found/usr/local/bin/node:~/node$ node --versionv8.1.1 (compiled by myself)

Questa è una soluzione semplice ed efficace, specialmente se un pacchetto software è fatto di pochi programmi eseguibili ben noti— dal momento che devi creare un collegamento simbolico per ogni comando invocato dall’utente. Ad esempio, se hai familiarità con NodeJS, conosci anche l’applicazione companion npm Che dovrei collegare simbolicamente da /usr/local/bin. Ma ho lasciato che a voi come un esercizio.

la Modifica del PERCORSO

in Primo luogo, se hai provato la soluzione precedente, rimuovere il nodo di collegamento simbolico creato in precedenza per l’avvio da un evidente stato:

:~/node$ sudo rm /usr/local/bin/node:~/node$ which -a node || echo not foundnot found

E ora, ecco la magia di comando per modificare il PATH:

:~/node$ export PATH="/opt/node/bin:${PATH}":~/node$ echo $PATH/opt/node/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

disse Semplicemente, ho sostituito il contenuto del tag PATH variabile di ambiente, il suo contenuto precedente, ma preceduto da /opt/node/bin. Quindi, come puoi immaginarlo ora, la shell guarderà prima nella directory/opt/node/bin per i programmi eseguibili. Possiamo confermare che l’utilizzo di which comando:

:~/node$ which -a node || echo not found/opt/node/bin/node:~/node$ node --versionv8.1.1 (compiled by myself)

Mentre il “link” soluzione permanente appena hai creato il link simbolico in /usr/local/binPATH modifica è efficace solo nella shell corrente. Ti lascerò fare qualche ricerca su come apportare modifiche ai permanenti PATH. Come suggerimento, ha a che fare con il tuo “profilo”. Se trovi la soluzione, non esitare a condividerla con gli altri lettori utilizzando la sezione commenti qui sotto!

E. Come rimuovere il software installato di recente dal codice sorgente

Dal momento che la nostra abitudine compilato NodeJS software si trova completamente nel /opt/node-v8.1.1 directory, la rimozione di software che non richiede sforzo in più che usare il comando rm per rimuovere la directory in cui:

sudo rm -rf /opt/node-v8.1.1

ATTENZIONE: sudo e rm -rf sono un cocktail pericoloso! Controllare sempre il comando due volte prima di premere il tasto “invio”. Non avrai alcun messaggio di conferma e nessun undelete se rimuovi la directory sbagliata

Quindi, se hai modificato il tuoPATH, dovrai ripristinare quelle modifiche, il che non è affatto complicato.

E se hai creato collegamenti da /usr/local/bin dovrai rimuoverli tutti:

:~/node$ sudo find /usr/local/bin \ -type l \ -ilname "/opt/node/*" \ -print -delete/usr/local/bin/node

Aspetta? Dov’era l’inferno della dipendenza?

Come commento finale, se leggi la compilazione del tuo software personalizzato, potresti aver sentito parlare dell’inferno delle dipendenze. Questo è un soprannome per quella fastidiosa situazione in cui prima di essere in grado di compilare con successo un software, è necessario prima compilare una libreria pre-requisito, che a sua volta richiede un’altra libreria che potrebbe a sua volta essere incompatibile con qualche altro software che hai già installato.

Parte del lavoro dei manutentori dei pacchetti della tua distribuzione è quello di risolvere effettivamente quell’inferno di dipendenza e di assicurare che i vari software del tuo sistema stiano usando librerie compatibili e siano installati nel giusto ordine.

Per questo articolo, ho scelto, di proposito, di installare NodeJS in quanto praticamente non ha dipendenze. Ho detto “virtualmente” perché, in effetti, ha dipendenze. Ma il codice sorgente di tali dipendenze è presente nel repository sorgente del progetto (nella sottodirectory node/deps), quindi non è necessario scaricarli e installarli manualmente prima della mano.