Pourquoi la commande openssl fonctionne alors que la compilation du VPN échoue

Le terminal rapporte volontiers une version d’OpenSSL, et l’arborescence source échoue toujours avec un message sur des en-têtes cryptographiques manquants. Les deux affirmations sont vraies en même temps, car un outil d’exécution et un ensemble d’entrées de compilation sont livrés séparément. Faites ces quatre vérifications dans l’ordre : paquets installés, sortie de découverte, chemins de recherche, puis la compatibilité de la source elle-même. Arrêtez-vous à la première qui explique l’échec au lieu de coller une ancienne liste de dépendances.

L’exécution et les entrées de compilation sont des paquets distincts

Une distribution divise OpenSSL en un paquet d’exécution qui fournit la bibliothèque partagée et l’outil en ligne de commande, et un paquet de développement qui fournit les en-têtes, les noms de liaison sans version et les métadonnées pkg-config. Installer le premier n’installe pas le second, et le compilateur n’a besoin que du second.

Vérifiez ce qui est réellement présent plutôt que ce dont vous vous souvenez avoir installé. Sur les systèmes dérivés de Debian, le paquet de développement est généralement libssl-dev, tandis que l’exécution est un paquet de bibliothèque versionné plus le binaire openssl.

dpkg -l | grep -E 'libssl-dev|libssl3|openssl'
pkg-config --modversion openssl
openssl version

La première commande montre lequel des trois est installé, la deuxième rapporte la version que le système de compilation découvrira via pkg-config, et la troisième rapporte la version d’exécution. Une ligne manquante dans la première sortie explique l’erreur immédiatement. Un écart de version entre la deuxième et la troisième est un autre problème, et il signifie généralement que deux installations se concurrencent.

Lisez la sortie de découverte de la compilation elle-même

La plupart des échecs sont visibles dans le journal de configuration si vous le lisez avant le résumé. Le module FindOpenSSL de CMake indique quel répertoire d’inclusion et quelles bibliothèques il a trouvés, et il échoue avec un message précis lorsqu’un composant requis est absent.

Confirmez quelle version du module le projet utilise, car une copie intégrée dans l’arborescence source peut se comporter différemment de celle livrée avec le CMake installé. Lisez ensuite la liste des composants : un projet qui ne demande que Crypto n’a pas besoin de la bibliothèque SSL, et un projet qui demande SSL échouera si seule une partie du paquet de développement est présente.

cmake -S . -B build -DCMAKE_BUILD_TYPE=Release
grep -i -E 'openssl|ssl' build/CMakeCache.txt

La première commande reconfigure depuis zéro, et la seconde montre les résultats mis en cache, y compris tout répertoire racine ou chemin de bibliothèque sur lequel le module s’est arrêté. Si le cache pointe vers un ancien préfixe d’une tentative précédente, supprimez le répertoire de compilation et reconfigurez plutôt que de modifier des valeurs à la main. Les entrées de cache obsolètes sont une cause fréquente d’un échec qui survit à une correction juste.

Orientez la compilation vers la bonne installation, de façon étroite

Lorsqu’un OpenSSL approuvé réside hors du chemin de recherche par défaut, FindOpenSSL documente OPENSSL_ROOT_DIR comme une indication pour cette compilation précise. Sur les systèmes de type Unix, il consulte aussi pkg-config, si bien qu’un PKG_CONFIG_PATH approprié peut aider sans rien changer globalement.

cmake -S . -B build -DOPENSSL_ROOT_DIR=/opt/openssl-3.2 -DCMAKE_BUILD_TYPE=Release
ldd build/vpn_client | grep -i ssl

La première commande limite l’indication à un seul répertoire de compilation, et la seconde montre quelle bibliothèque partagée le binaire obtenu chargera à l’exécution. Une compilation liée au préfixe prévu et un binaire qui en charge un autre relèvent d’un problème de chemin d’exécution, non d’un problème de découverte, et cela demande une décision sur rpath ou la configuration du chargeur plutôt qu’une nouvelle option de configuration.

Gardez ces choix locaux à la compilation. Remplacer des bibliothèques système ou modifier des fichiers pkg-config globaux pour satisfaire un seul projet est la façon dont un bureau qui fonctionne devient cassé. Un répertoire de compilation qui enregistre le préfixe est reproductible ; un changement à l’échelle de la machine est un incident de support qui attend le projet suivant. Supprimez le répertoire de compilation lorsque vous changez l’indication, afin que le cache ne puisse pas conserver l’ancienne réponse.

Sachez quand le problème vient de la source

Une étape de configuration réussie prouve seulement que les vérifications se sont terminées. La compilation peut encore rejeter une API que la source attend, et l’édition de liens peut encore échouer sur un symbole manquant. Conservez la première erreur précise de chaque étape, car les suivantes sont généralement des conséquences.

OpenSSL 3 a déprécié puis supprimé plusieurs interfaces que les anciens clients VPN utilisent directement, si bien qu’une arborescence source de cette époque peut nécessiter de vrais changements plutôt qu’un nouveau chemin d’inclusion. Si les mainteneurs prennent en charge une version actuelle, utilisez-la. Sinon, la décision revient à qui possède le service, pas à une recherche d’un ancien nom de fichier de bibliothèque.

Les composants de bureau facultatifs ont aussi leurs exigences. Une cible en ligne de commande qui se configure proprement ne dit rien de la compilation de la boîte à outils GUI et de l’éditeur, alors traitez une ancienne liste de paquets Qt comme de l’histoire et non comme une spécification. Vérifiez les options propres à la révision source pour savoir quelles interfaces sont activées par défaut. Ensuite, ne compilez que ce dont vous avez besoin, car chaque dépendance facultative est un autre problème de découverte en attente.