Perché il comando openssl funziona ma la compilazione della VPN fallisce
Un binario openssl funzionante non dice nulla sugli header e sulle librerie di collegamento. Controllate il pacchetto di sviluppo, l’architettura di destinazione e il registro di scoperta della compilazione.
Il terminale riporta volentieri una versione di OpenSSL, e l’albero dei sorgenti continua a fallire con un messaggio su header crittografici mancanti. Entrambe le affermazioni sono vere insieme, perché uno strumento di runtime e un insieme di input di compilazione vengono distribuiti separatamente. Eseguite questi quattro controlli in ordine: pacchetti installati, output di scoperta, percorsi di ricerca e infine se il sorgente stesso è compatibile. Fermatevi al primo che spiega l’errore invece di incollare un vecchio elenco di dipendenze.
Runtime e input di compilazione sono pacchetti diversi
Una distribuzione divide OpenSSL in un pacchetto di runtime che fornisce la libreria condivisa e lo strumento da riga di comando, e in un pacchetto di sviluppo che fornisce header, nomi di collegamento senza versione e metadati pkg-config. Installare il primo non installa il secondo, e il compilatore ha bisogno solo del secondo.
Controllate ciò che è realmente presente e non ciò che ricordate di aver installato. Nei sistemi derivati da Debian il pacchetto di sviluppo è di solito libssl-dev, mentre il runtime è un pacchetto di libreria con versione più il binario openssl.
dpkg -l | grep -E 'libssl-dev|libssl3|openssl' pkg-config --modversion openssl openssl version
Il primo comando mostra quale dei tre è installato, il secondo riporta la versione che il sistema di compilazione scoprirà tramite pkg-config, e il terzo riporta la versione di runtime. Una riga mancante nel primo output spiega subito l’errore. Una discrepanza di versione tra il secondo e il terzo è un altro problema, e di solito significa che due installazioni si contendono il posto.
Leggete l’output di scoperta della compilazione stessa
La maggior parte degli errori è visibile nel registro di configurazione se lo leggete prima del riepilogo. Il modulo FindOpenSSL di CMake riporta quale directory di inclusione e quali librerie ha trovato, e fallisce con un messaggio specifico quando manca un componente richiesto.
Verificate quale versione del modulo usa il progetto, perché una copia inclusa nell’albero dei sorgenti può comportarsi diversamente da quella fornita con il CMake installato. Poi leggete l’elenco dei componenti: un progetto che chiede solo Crypto non ha bisogno della libreria SSL, e uno che chiede SSL fallirà se è presente solo una parte del pacchetto di sviluppo.
cmake -S . -B build -DCMAKE_BUILD_TYPE=Release grep -i -E 'openssl|ssl' build/CMakeCache.txt
Il primo comando riconfigura da zero, e il secondo mostra i risultati in cache, compresa qualsiasi directory radice o percorso di libreria su cui il modulo si è fermato. Se la cache punta a un prefisso vecchio di un tentativo precedente, cancellate la directory di compilazione e riconfigurate invece di modificare i valori a mano. Le voci obsolete della cache sono una causa comune di un errore che sopravvive a una correzione corretta.
Indirizzate la compilazione all’installazione giusta, in modo stretto
Quando un OpenSSL approvato vive fuori dal percorso di ricerca predefinito, FindOpenSSL documenta OPENSSL_ROOT_DIR come suggerimento per quella specifica compilazione. Sui sistemi simili a Unix consulta anche pkg-config, quindi un PKG_CONFIG_PATH adeguato può aiutare senza cambiare nulla a livello globale.
cmake -S . -B build -DOPENSSL_ROOT_DIR=/opt/openssl-3.2 -DCMAKE_BUILD_TYPE=Release ldd build/vpn_client | grep -i ssl
Il primo comando limita il suggerimento a una sola directory di compilazione, e il secondo mostra quale libreria condivisa il binario risultante caricherà in fase di esecuzione. Una compilazione che si collega al prefisso previsto e un binario che ne carica un altro sono un problema di percorso di runtime, non un problema di scoperta, e richiedono una decisione su rpath o sulla configurazione del loader invece di un’altra opzione di configurazione.
Mantenete queste scelte locali alla compilazione. Sostituire librerie di sistema o modificare file pkg-config globali per soddisfare un solo progetto è il modo in cui una scrivania funzionante diventa rotta. Una directory di compilazione che registra il prefisso è riproducibile; una modifica a tutta la macchina è un incidente di supporto in attesa del progetto successivo. Cancellate la directory di compilazione quando cambiate il suggerimento, così che la cache non possa conservare la vecchia risposta.
Sappiate quando il problema è il sorgente
Un passo di configurazione riuscito dimostra solo che i controlli sono stati completati. La compilazione può ancora rifiutare un’API che il sorgente si aspetta, e il collegamento può ancora fallire per un simbolo mancante. Conservate il primo errore specifico di ogni fase, perché i successivi sono di solito conseguenze.
OpenSSL 3 ha dichiarato obsolete e rimosso diverse interfacce che i client VPN più vecchi usano direttamente, quindi un albero dei sorgenti di quell’epoca può richiedere modifiche reali invece di un nuovo percorso di inclusione. Se i manutentori supportano una versione attuale, usatela. Se no, la decisione spetta a chi possiede il servizio, non a una ricerca di un nome di file di libreria più vecchio.
Anche i componenti opzionali della scrivania hanno i loro requisiti. Un target da riga di comando che si configura in modo pulito non dice nulla sulla compilazione del toolkit GUI e dell’editor, quindi trattate un vecchio elenco di pacchetti Qt come storia e non come specifica. Controllate le opzioni proprie della revisione dei sorgenti per sapere quali interfacce sono abilitate per impostazione predefinita. Poi compilate solo ciò che vi serve, perché ogni dipendenza opzionale è un altro problema di scoperta in attesa di accadere.