openssl आदेश किन काम गर्छ तर VPN बिल्ड किन असफल हुन्छ

टर्मिनलले खुसीसाथ OpenSSL संस्करण रिपोर्ट गर्छ, र स्रोत रूख अझै पनि हराइरहेका क्रिप्टो हेडरबारे सन्देशसहित असफल हुन्छ। दुवै भनाइ एकै समयमा सत्य हुन्, किनकि रनटाइम उपकरण र बिल्ड इनपुटको समूह छुट्टै पठाइन्छ। यी चार जाँच क्रममा गर्नुहोस्: स्थापित प्याकेज, खोज आउटपुट, खोज मार्ग, र त्यसपछि स्रोत आफैं मिल्दो छ कि छैन। पुरानो निर्भरता सूची टाँस्नुको सट्टा असफलता बुझाउने पहिलो जाँचमा रोकिनुहोस्।

रनटाइम र बिल्ड इनपुट फरक प्याकेज हुन्

एउटा वितरणले OpenSSL लाई साझा लाइब्रेरी र आदेश-लाइन उपकरण दिने रनटाइम प्याकेजमा, र हेडर, संस्करणरहित लिङ्कर नाम र pkg-config मेटाडाटा दिने विकास प्याकेजमा विभाजन गर्छ। पहिलो स्थापना गर्दा दोस्रो स्थापना हुँदैन, र कम्पाइलरलाई दोस्रो मात्र चाहिन्छ।

तपाईंले स्थापना गरेको सम्झनुको सट्टा वास्तवमा के छ त्यो जाँच गर्नुहोस्। Debian आधारित प्रणालीमा विकास प्याकेज सामान्यतया libssl-dev हुन्छ, जबकि रनटाइम संस्करण भएको लाइब्रेरी प्याकेज र openssl बाइनरी हो।

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

पहिलो आदेशले तीनमध्ये कुन स्थापित छ देखाउँछ, दोस्रोले बिल्ड प्रणालीले pkg-config मार्फत फेला पार्ने संस्करण बताउँछ, र तेस्रोले रनटाइम संस्करण बताउँछ। पहिलो आउटपुटमा हराएको लाइनले त्रुटि तुरुन्तै बुझाउँछ। दोस्रो र तेस्रोबीचको संस्करण भिन्नता अर्को समस्या हो, र सामान्यतया दुई स्थापना प्रतिस्पर्धा गरिरहेको अर्थ दिन्छ।

बिल्डको आफ्नै खोज आउटपुट पढ्नुहोस्

सारांशअघि पढ्दा अधिकांश असफलता कन्फिगर लगमा देखिन्छ। CMake को FindOpenSSL मोड्युलले कुन include डाइरेक्टरी र कुन लाइब्रेरी भेट्यो बताउँछ, र आवश्यक घटक नभएमा विशिष्ट सन्देशसहित असफल हुन्छ।

परियोजनाले कुन मोड्युल संस्करण प्रयोग गर्छ निश्चित गर्नुहोस्, किनकि स्रोत रूखभित्र बन्डल गरिएको प्रतिलिपि स्थापित CMake सँग आउनेभन्दा फरक व्यवहार गर्न सक्छ। त्यसपछि घटक सूची पढ्नुहोस्: Crypto मात्र माग्ने परियोजनालाई SSL लाइब्रेरी चाहिँदैन, र SSL माग्ने परियोजना विकास प्याकेजको एउटा भाग मात्र भएमा असफल हुन्छ।

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

पहिलो आदेश सुरुदेखि पुनः कन्फिगर गर्छ, र दोस्रोले मोड्युल अडिएको कुनै पनि मूल डाइरेक्टरी वा लाइब्रेरी मार्गसहित क्यास गरिएका नतिजा देखाउँछ। क्यासले अघिल्लो प्रयासको पुरानो प्रिफिक्सतर्फ संकेत गर्छ भने, मान हातले सम्पादन गर्नुको सट्टा बिल्ड डाइरेक्टरी मेट्नुहोस् र फेरि कन्फिगर गर्नुहोस्। बासी क्यास प्रविष्टिहरू सही सुधारपछि पनि रहने असफलताको सामान्य कारण हुन्।

बिल्डलाई सही स्थापनातर्फ साँघुरो रूपमा निर्देशित गर्नुहोस्

स्वीकृत OpenSSL पूर्वनिर्धारित खोज मार्गबाहिर रहेमा, FindOpenSSL ले OPENSSL_ROOT_DIR लाई त्यही निर्दिष्ट बिल्डका लागि संकेतका रूपमा अभिलेख गर्छ। Unix जस्ता प्रणालीमा यसले pkg-config सँग पनि सोध्छ, त्यसैले उपयुक्त PKG_CONFIG_PATH ले विश्वव्यापी रूपमा केही नबदली मद्दत गर्न सक्छ।

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

पहिलो आदेशले संकेतलाई एउटा बिल्ड डाइरेक्टरीमा सीमित गर्छ, र दोस्रोले नतिजा बाइनरीले रनटाइममा कुन साझा लाइब्रेरी लोड गर्छ देखाउँछ। इच्छित प्रिफिक्ससँग लिङ्क हुने बिल्ड र अर्को लोड गर्ने बाइनरी रनटाइम मार्गको समस्या हो, खोजको समस्या होइन, र यसका लागि अर्को कन्फिगर फ्ल्यागको सट्टा rpath वा लोडर कन्फिगरेसनको निर्णय चाहिन्छ।

यी छनोटहरू बिल्डभित्रै स्थानीय राख्नुहोस्। एउटा परियोजना सन्तुष्ट पार्न प्रणाली लाइब्रेरी बदल्ने वा विश्वव्यापी pkg-config फाइल सम्पादन गर्ने काम गर्ने डेस्कटप बिग्रिएको बनाउने बाटो हो। प्रिफिक्स अभिलेख गर्ने बिल्ड डाइरेक्टरी पुनरुत्पादनयोग्य हुन्छ; सम्पूर्ण मेसिनभरिको परिवर्तन अर्को परियोजनाको प्रतीक्षामा रहेको सहयोग घटना हो। संकेत बदल्दा बिल्ड डाइरेक्टरी मेट्नुहोस्, ताकि क्यासले पुरानो उत्तर राख्न नसकोस्।

समस्या स्रोतमै छ कहिले भनेर जान्नुहोस्

सफल कन्फिगर चरणले जाँच पूरा भएको मात्र प्रमाणित गर्छ। कम्पाइलेसनले स्रोतले अपेक्षा गरेको API अस्वीकार गर्न सक्छ, र लिङ्किङ हराइरहेको प्रतीकका कारण असफल हुन सक्छ। प्रत्येक चरणको पहिलो विशिष्ट त्रुटि राख्नुहोस्, किनकि पछिका सामान्यतया परिणाम हुन्।

OpenSSL 3 ले पुराना VPN क्लाइन्टहरूले सिधै प्रयोग गर्ने धेरै इन्टरफेसलाई अप्रचलित घोषणा गरी हटायो, त्यसैले त्यस युगको स्रोत रूखलाई नयाँ include मार्गको सट्टा वास्तविक परिवर्तन चाहिन सक्छ। यदि मर्मतकर्ताहरूले वर्तमान संस्करण समर्थन गर्छन् भने त्यही प्रयोग गर्नुहोस्। नगरेमा, निर्णय सेवाको मालिकको हो, पुरानो लाइब्रेरी फाइल नामको खोजको होइन।

वैकल्पिक डेस्कटप घटकका पनि आफ्नै आवश्यकता हुन्छन्। सफासँग कन्फिगर हुने आदेश-लाइन लक्ष्यले GUI उपकरण समूह र सम्पादक बन्छन् कि भन्नेबारे केही बताउँदैन, त्यसैले पुरानो Qt प्याकेज सूचीलाई विशिष्टताका रूपमा नभई इतिहासका रूपमा लिनुहोस्। कुन इन्टरफेस पूर्वनिर्धारित रूपमा सक्रिय छन् स्रोत संस्करणकै विकल्पमा जाँच गर्नुहोस्। त्यसपछि आवश्यक भएको मात्र बिल्ड गर्नुहोस्, किनकि हरेक वैकल्पिक निर्भरता हुन बाँकी अर्को खोज समस्या हो।