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 पॅकेज यादी विनिर्देश म्हणून नव्हे तर इतिहास म्हणून घ्या। कोणते इंटरफेस डीफॉल्टने सक्षम आहेत हे स्रोत आवृत्तीच्या स्वतःच्या पर्यायांमध्ये तपासा। नंतर गरजेचे तेवढेच बिल्ड करा, कारण प्रत्येक पर्यायी अवलंबन ही घडण्याची वाट पाहणारी आणखी एक डिस्कव्हरी समस्या आहे।