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 પેકેજ સૂચિને સ્પેસિફિકેશનને બદલે ઇતિહાસ તરીકે ગણો. સ્રોત પુનરાવર્તનના પોતાના વિકલ્પોમાં જુઓ કે કયા ઇન્ટરફેસ ડિફૉલ્ટ રીતે સક્ષમ છે. પછી ફક્ત જે જોઈએ તે બનાવો, કારણ કે દરેક વૈકલ્પિક નિર્ભરતા એ બનવાની રાહ જોતી બીજી ડિસ્કવરી સમસ્યા છે.