Installare build-essential su Ubuntu 22.04 e 20.04 LTS

Perché build-essential serve davvero su Ubuntu LTS

Su Ubuntu 22.04 e 20.04 LTS il pacchetto build-essential non è un compilatore unico, ma un metapacchetto che porta dentro il minimo sensato per costruire software nativo in C e C++. In pratica installa gli strumenti base che ti aspetti su una macchina di sviluppo, su un server di staging o su un ambiente dove devi compilare moduli, librerie o software da sorgente senza inseguire dipendenze una per una.

La differenza tra “ho gcc installato” e “ho un ambiente di build utilizzabile” è più grande di quanto sembri. Con build-essential ti porti dietro il compilatore, il linker e i pacchetti di base per il ciclo di compilazione. Questo evita errori banali del tipo make: command not found o header mancanti quando un installer da sorgente prova a compilare un componente nativo.

Su Ubuntu LTS il pacchetto è presente nei repository ufficiali, quindi la strada corretta è quasi sempre quella standard: aggiornare l’indice APT e installare il metapacchetto. Il punto non è tanto “come si installa”, ma come verificare che il sistema sia pronto, che i repository siano sani e che il toolchain sia effettivamente operativo.

Installazione standard su Ubuntu 22.04 e 20.04

Se hai un sistema pulito e una connettività normale, bastano pochi passaggi. Il flusso corretto è: aggiornare l’indice dei pacchetti, installare build-essential e poi verificare la presenza dei binari principali.

Comandi essenziali:

sudo apt update
sudo apt install build-essential

Se vuoi controllare subito cosa è stato installato, puoi interrogare APT e i binari nel PATH:

dpkg -l | grep -E '^ii\s+build-essential|^ii\s+gcc|^ii\s+g\+\+|^ii\s+make'
which gcc g++ make
gcc --version
make --version

Su Ubuntu 22.04 e 20.04 l’output atteso è semplice: i pacchetti risultano installati, which restituisce un percorso come /usr/bin/gcc e i comandi di versione rispondono senza errori. Se uno di questi controlli fallisce, non dare per scontato che il problema sia nel pacchetto: spesso è il repository APT, il PATH dell’utente o una installazione parziale.

Cosa installa build-essential, davvero

Il contenuto del metapacchetto può variare leggermente tra release, ma il concetto resta lo stesso: include il minimo per compilare software C/C++ in modo standard. In genere trovi gcc, g++, make e i pacchetti di supporto necessari alla toolchain di base. In molti casi vengono portate anche librerie e header di sistema richiesti per compilazioni comuni.

Per vedere esattamente cosa dipende dal metapacchetto nella tua release, usa APT invece di fidarti di liste prese a memoria:

apt show build-essential
apt-cache depends build-essential

Questo è utile soprattutto in ambienti misti, dove vuoi sapere se il nodo è davvero allineato a 20.04 o 22.04 e non stai ereditando pacchetti da una configurazione precedente. Se stai preparando un server per compilazioni sporadiche, il metapacchetto è la scelta più pulita: meno ambiguità, meno installazioni manuali, meno drift.

Verifiche rapide prima e dopo l’installazione

In troubleshooting serio la domanda non è “si installa?”, ma “il sistema è nelle condizioni corrette per installarlo e usarlo?”. Prima di toccare il pacchetto, conviene verificare tre cose: repository raggiungibili, spazio disco sufficiente e nessun lock APT bloccato da un processo parallelo.

Controlli rapidi:

sudo apt update
df -h /
ps aux | grep -E '[a]pt|[d]pkg'

Se apt update fallisce, l’installazione di build-essential è solo il sintomo. In quel caso il problema può stare in DNS, proxy, mirror o repository disabilitati. Se il filesystem root è vicino al 100%, apt può fermarsi a metà e lasciarti in uno stato incoerente. Se c’è un lock, fermati: non forzare lo sblocco senza capire quale processo sta davvero operando.

Dopo l’installazione, un controllo utile è compilare un file minimo di test. Non serve nulla di complesso: basta verificare che il toolchain sia completo e che il linker funzioni.

cat > /tmp/test.c <<'EOF'
#include <stdio.h>
int main(void) {
    puts("ok");
    return 0;
}
EOF

gcc /tmp/test.c -o /tmp/test && /tmp/test

L’output atteso è ok. Se la compilazione fallisce, il problema non è più l’installazione del metapacchetto in sé, ma un guasto più specifico: toolchain non coerente, binari mancanti, librerie di sviluppo assenti o ambiente utente compromesso.

Differenze pratiche tra 20.04 e 22.04

Per installare build-essential il comando è identico sulle due release. Le differenze utili stanno altrove: versione dei compilatori, librerie disponibili nei repository e comportamento di alcuni pacchetti di sviluppo nel tempo. Su 22.04 il toolchain di base tende a essere più recente, mentre su 20.04 puoi trovarti in scenari dove un software moderno richiede versioni minime di GCC o librerie non allineate alla release.

Questo non cambia il pacchetto da installare, ma cambia la strategia. Se il tuo obiettivo è compilare un software specifico, prima controlla i requisiti upstream. Un esempio tipico: un progetto può richiedere C++17, una versione di GCC precisa o header aggiuntivi che build-essential non porta da solo. In quel caso il metapacchetto è solo la base, non la soluzione completa.

Se vuoi capire la versione del compilatore installata, usa:

gcc --version
g++ --version
lsb_release -a

Il punto operativo è semplice: la procedura di installazione non cambia, ma il contesto sì. Su un server 20.04 vecchio di anni, spesso conviene verificare anche la presenza di repository di sicurezza aggiornati e di eventuali pinning APT che possano bloccare il download di pacchetti coerenti con la release.

Problemi tipici: repository, proxy, DNS e lock APT

Quando build-essential non si installa, la causa più frequente non è il pacchetto ma il contesto. I casi classici sono repository non raggiungibili, DNS rotto, proxy aziendale non configurato, mirror lento o lock lasciato da aggiornamenti automatici.

Se il problema è di rete, inizia dalla risoluzione DNS e dal reachability test verso i mirror Ubuntu:

resolvectl status
curl -I https://archive.ubuntu.com/ubuntu/
ping -c 3 archive.ubuntu.com

Se sei dietro proxy, verifica che siano configurate le variabili o i file di APT corretti. In ambienti server non è raro che il browser funzioni e apt no, semplicemente perché il proxy è definito solo a livello utente o non è passato al servizio che esegue gli aggiornamenti.

Per i lock APT, controlla il processo reale prima di intervenire:

sudo lsof /var/lib/dpkg/lock-frontend
sudo lsof /var/lib/dpkg/lock

Se c’è un processo legittimo in corso, aspetta. Se invece il sistema è rimasto bloccato dopo un crash o una sessione interrotta, il percorso corretto è ripristinare la coerenza di dpkg con prudenza, non cancellare file a mano senza capire lo stato del database pacchetti.

Installazione in ambienti minimali, container e server headless

In un’installazione minimale di Ubuntu Server o in un container, build-essential può essere installato senza problemi, ma devi distinguere tra ambiente di build e ambiente runtime. Su un container leggero spesso ha senso installarlo solo in uno stage di compilazione e non nel layer finale, per tenere l’immagine più piccola e ridurre la superficie d’attacco.

Se usi una pipeline multi-stage, il pacchetto entra nello stage builder e poi il binario compilato viene copiato nell’immagine finale. In un server tradizionale, invece, può essere utile tenerlo installato se fai manutenzione frequente, compili moduli PHP, estensioni Python con componenti nativi o software di terze parti distribuito solo in sorgente.

Attenzione però alla disciplina operativa: più toolchain lasci installata, più aumenti la superficie di manutenzione. Se il server è un origin di produzione e non un host di sviluppo, conviene documentare perché il pacchetto è presente e chi lo usa. In ambienti regolati, questo aiuta anche l’audit minimo dei software installati.

Quando serve qualcosa oltre build-essential

Molti installer da sorgente danno per scontato che build-essential basti, ma spesso servono anche pacchetti aggiuntivi: header per SSL, zlib, XML, JPEG, readline o altri componenti specifici. Se la compilazione si ferma su un errore del tipo fatal error: xyz.h: No such file or directory, non stai guardando un problema di build-essential ma una dipendenza mancata.

La regola pratica è: installa il metapacchetto per la base, poi legge gli errori di compilazione come elenco puntuale delle librerie mancanti. Evita di installare pacchetti “a caso” solo perché sembrano correlati. Meglio verificare l’header richiesto, il pacchetto che lo fornisce e la release Ubuntu in uso.

Un controllo utile è interrogare il database dei pacchetti per vedere chi fornisce un certo file header:

sudo apt-file update
apt-file search xyz.h

Questo approccio è molto più pulito rispetto al tentativo di “indovinare” il pacchetto corretto. Su macchine usate da più team, riduce anche il rischio di accumulare dipendenze inutili e di perdere traccia del motivo per cui una libreria è stata installata.

Rimozione, audit e manutenzione minima

Se non ti serve più, puoi rimuovere build-essential come qualsiasi altro pacchetto APT. In un ambiente di produzione, però, la rimozione va valutata con attenzione: se ci sono script di manutenzione, moduli compilati o procedure operative che si appoggiano a gcc/make, togliere il pacchetto può rompere attività future senza un errore immediato.

Per un audit rapido, controlla quali componenti sono presenti e se qualcuno li usa davvero:

dpkg -l | grep -E '^ii\s+(build-essential|gcc|g\+\+|make|libc6-dev)'
apt-mark showmanual | grep -E 'build-essential|gcc|g\+\+|make'

Se l’host è dedicato a runtime e non a build, una pulizia periodica ha senso. Se invece è un nodo di amministrazione, un jump host o una macchina di staging, la presenza del toolchain è normale. L’importante è sapere perché c’è, non lasciarlo lì per inerzia.

Sequenza consigliata da usare in pratica

Se vuoi una procedura asciutta e ripetibile, questa è la sequenza che uso in genere su Ubuntu 22.04 e 20.04 LTS:

1. Verifica connettività e repository con sudo apt update.
2. Controlla spazio disco con df -h /.
3. Installa il metapacchetto con sudo apt install build-essential.
4. Valida i binari con which gcc g++ make.
5. Fai un test di compilazione minimale con un file C di prova.
6. Se fallisce, leggi il messaggio e installa solo le dipendenze realmente mancanti.

Questa sequenza riduce il rumore diagnostico. Ti evita di confondere un problema di rete con uno di compilazione, o un lock di sistema con un repository rotto. Nelle attività quotidiane è proprio qui che si risparmia tempo: non nella velocità del comando, ma nella qualità delle verifiche prima di cambiare altro.

Comando minimo da ricordare

Se ti serve solo il riferimento rapido, questo è il comando base per entrambe le release:

sudo apt update && sudo apt install build-essential

Il resto del lavoro sta nella verifica: capire se l’installazione è andata a buon fine, se il sistema è davvero pronto per compilare e se ti servono librerie aggiuntive rispetto al metapacchetto. Su Ubuntu LTS, la parte facile è installarlo; la parte professionale è sapere quando basta e quando no.