کیوں 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 پیکیج فہرست کو تفصیل کے بجائے تاریخ سمجھیں۔ کون سے انٹرفیس ڈیفالٹ میں فعال ہیں یہ سورس ریویژن کے اپنے اختیارات میں چیک کریں۔ پھر صرف وہی بنائیں جو آپ کو درکار ہے، کیونکہ ہر اختیاری انحصار واقع ہونے کے انتظار میں ایک اور ڈسکوری مسئلہ ہے۔