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 पैकेज सूची को विनिर्देश के बजाय इतिहास मानें। स्रोत संशोधन के अपने विकल्पों में देखें कि कौन-से इंटरफ़ेस डिफ़ॉल्ट रूप से सक्षम हैं। फिर केवल वही बनाएँ जो आपको चाहिए, क्योंकि हर वैकल्पिक निर्भरता होने की प्रतीक्षा करती एक और डिस्कवरी समस्या है।