Varför openssl-kommandot fungerar men VPN-bygget misslyckas
En fungerande openssl-binär säger ingenting om huvuden och länkbibliotek. Kontrollera utvecklingspaketet, målarkitekturen och byggets söklogg.
Terminalen rapporterar gladeligen en OpenSSL-version, och källkodsträdet misslyckas fortfarande med ett meddelande om saknade kryptohuvuden. Båda påståendena är sanna samtidigt, eftersom ett körtidsverktyg och en uppsättning byggindata levereras separat. Gör dessa fyra kontroller i ordning: installerade paket, sökutdata, sökvägar och till sist om själva källan är kompatibel. Stanna vid den första som förklarar felet i stället för att klistra in en gammal beroendelista.
Körtid och byggindata är olika paket
En distribution delar OpenSSL i ett körtidspaket som tillhandahåller det delade biblioteket och kommandoradsverktyget, och ett utvecklingspaket som tillhandahåller huvuden, overitionerade länknamn och pkg-config-metadata. Att installera det första installerar inte det andra, och kompilatorn behöver bara det andra.
Kontrollera vad som faktiskt finns i stället för vad du minns att du installerade. På Debian-baserade system är utvecklingspaketet vanligtvis libssl-dev, medan körtiden är ett versionerat bibliotekspaket plus openssl-binären.
dpkg -l | grep -E 'libssl-dev|libssl3|openssl' pkg-config --modversion openssl openssl version
Det första kommandot visar vilket av de tre som är installerat, det andra rapporterar den version som byggsystemet hittar via pkg-config, och det tredje rapporterar körtidsversionen. En saknad rad i den första utdatan förklarar felet omedelbart. En versionsskillnad mellan den andra och den tredje är ett annat problem, och betyder vanligtvis att två installationer konkurrerar.
Läs byggets egen sökutdata
De flesta fel är synliga i konfigurationsloggen om du läser den före sammanfattningen. FindOpenSSL-modulen i CMake rapporterar vilken inkluderingskatalog och vilka bibliotek den hittade, och den misslyckas med ett specifikt meddelande när en obligatorisk komponent saknas.
Bekräfta vilken modulversion projektet använder, eftersom en kopia som följer med i källkodsträdet kan bete sig annorlunda än den som levereras med den installerade CMake. Läs sedan komponentlistan: ett projekt som bara frågar efter Crypto behöver inte SSL-biblioteket, och ett som frågar efter SSL misslyckas om bara en del av utvecklingspaketet finns.
cmake -S . -B build -DCMAKE_BUILD_TYPE=Release grep -i -E 'openssl|ssl' build/CMakeCache.txt
Det första kommandot konfigurerar om från början, och det andra visar de cachade resultaten, inklusive varje rotkatalog eller bibliotekssökväg som modulen landade på. Om cachen pekar på ett gammalt prefix från ett tidigare försök, ta bort byggmappen och konfigurera om i stället för att redigera värden för hand. Föråldrade cacheposter är en vanlig orsak till ett fel som överlever en korrekt rättelse.
Rikta bygget mot rätt installation, snävt
När en godkänd OpenSSL ligger utanför standardsökvägen dokumenterar FindOpenSSL OPENSSL_ROOT_DIR som en ledtråd för just det bygget. På Unix-liknande system frågar den också pkg-config, så ett passande PKG_CONFIG_PATH kan hjälpa utan att ändra något globalt.
cmake -S . -B build -DOPENSSL_ROOT_DIR=/opt/openssl-3.2 -DCMAKE_BUILD_TYPE=Release ldd build/vpn_client | grep -i ssl
Det första kommandot begränsar ledtråden till en byggmapp, och det andra visar vilket delat bibliotek den resulterande binären laddar vid körning. Ett bygge som länkar mot det avsedda prefixet och en binär som laddar ett annat är ett körtidssökvägsproblem, inte ett sökproblem, och det kräver ett beslut om rpath eller laddarkonfiguration i stället för ännu en konfigureringsflagga.
Håll dessa val lokala för bygget. Att ersätta systembibliotek eller redigera globala pkg-config-filer för att tillfredsställa ett enda projekt är hur ett fungerande skrivbord blir ett trasigt. En byggmapp som registrerar prefixet är reproducerbar; en ändring för hela maskinen är en supportincident som väntar på nästa projekt. Ta bort byggmappen när du ändrar ledtråden, så att cachen inte kan behålla det gamla svaret.
Vet när källan är problemet
Ett lyckat konfigureringssteg bevisar bara att kontrollerna slutfördes. Kompileringen kan fortfarande avvisa ett API som källan förväntar sig, och länkningen kan fortfarande misslyckas på en saknad symbol. Spara det första konkreta felet från varje steg, eftersom de senare vanligtvis är konsekvenser.
OpenSSL 3 föråldrade och tog bort flera gränssnitt som äldre VPN-klienter använder direkt, så ett källkodsträd från den tiden kan behöva verkliga ändringar i stället för en ny inkluderingssökväg. Om underhållarna stöder en aktuell utgåva, använd den. Om inte, tillhör beslutet den som äger tjänsten, inte en sökning efter ett äldre biblioteksfilnamn.
Valfria skrivbordskomponenter har också sina egna krav. Ett kommandoradsmål som konfigureras rent säger ingenting om huruvida GUI-verktygslådan och redigeraren byggs, så behandla en gammal Qt-paketlista som historia och inte som specifikation. Kontrollera källrevisionens egna alternativ för vilka gränssnitt som är aktiverade som standard. Bygg sedan bara det du behöver, eftersom varje valfritt beroende är ännu ett sökproblem som väntar på att inträffa.