डिस्ट्रो नाव, glibc किंवा कंपायलर: इंस्टॉलर काय तपासतो

इंस्टॉलर “unsupported distribution” छापतो, तुम्ही एक स्ट्रिंग संपादित करता आणि तो एका मिनिटानंतर लोडर त्रुटीने अयशस्वी होईपर्यंत पुढे जातो. तो क्रम हेच ओळखण्यासारखे लक्षण आहे: पहिले अपयश ओळख तपासणी होते आणि दुसरे सुसंगततेची सीमा आहे. एकाच टर्मिनलमध्ये योगायोगाने दिसणाऱ्या या दोन वेगळ्या समस्या आहेत. तपासणी संपादित केल्याने तुम्ही पहिल्यापासून दुसऱ्याकडेच जाऊ शकता.

लक्षण: इंस्टॉलर तुमच्या डेरिव्हेटिव्हवर थांबतो

डिस्ट्रिब्युशनचे नाव वाचून पुढे जाण्यास नकार देणारी स्क्रिप्ट तुम्हाला सांगते की त्याच्या लेखकाने तुमचे डेरिव्हेटिव्ह तपासले नाही. हे तांत्रिक तथ्य नसून समर्थनाचे विधान आहे, आणि पॅकेज व्यवस्थित चालले असते या अर्थाने ते बऱ्याचदा चुकीचे असते.

अडचण तेव्हा सुरू होते जेव्हा तोडगा हाच आराखडा होतो. ओळख फाइल बदलल्याने तपासणी पास होते, आणि मग पॅकेज प्रत्यक्षात स्थापित रनटाइमविरुद्ध लोड होते, किंवा लोड होत नाही. तिथे अपयश आल्यास पुढील ओळख संपादन काहीही उपयोगी पडणार नाही.

म्हणून उपयुक्त पाऊल म्हणजे इंस्टॉलरने कोणता प्रश्न विचारला हे शोधणे, आणि नंतर उत्तराला महत्त्व असते का हे शोधणे. हे दोन वेगळे तपास आहेत आणि पॅकेज चालेल का हे फक्त दुसरेच सांगते.

लोक ज्याला सिस्टम आवृत्ती म्हणतात त्या तीन आवृत्त्या

डिस्ट्रिब्युशन प्रकाशन पॅकेज केलेल्या वातावरणाला नाव देते. C लायब्ररीची आवृत्ती रनटाइम अंमलबजावणी आणि तिच्या प्रकाशनाला नाव देते. कंपायलरची आवृत्ती टूलचेनला नाव देते. बोलण्यात लोक तीनहीना “सिस्टम आवृत्ती” म्हणतात, पण इंस्टॉलरमध्ये त्या परस्पर बदलण्यायोग्य नाहीत.

cat /etc/os-release
ldd --version | head -1
gcc --version | head -1
uname -m

आधीच तयार केलेले अनुप्रयोग ते लिंक झाले तेव्हा असलेल्या रनटाइमची अपेक्षा करते. होस्टवर कंपायलर बदलल्याने ते पुन्हा लिंक होत नाही, आणि नवीन टूलचेन बायनरी मागणाऱ्या लोडर चिन्हांमध्ये काहीही बदलत नाही. आर्किटेक्चर पुन्हा वेगळे महत्त्वाचे आहे, कारण 64-बिट सिस्टमवरील 32-बिट पॅकेज कोणत्याही आवृत्ती स्ट्रिंगने स्पष्ट न होणाऱ्या कारणांमुळे अयशस्वी होते.

चारही आउटपुट अहवालासोबत ठेवा. ते गोळा करायला दहा सेकंद लागतात आणि मेंटेनर ईमेलने विचारेल अशा बहुतेक प्रश्नांची उत्तरे देतात.

त्रुटी वाचा, तपासणी नाही

पहिली लाँच त्रुटी हाच पुरावा आहे. गहाळ सामायिक ऑब्जेक्टबद्दल, किंवा लोडर पूर्ण करू शकत नाही अशा चिन्ह आवृत्तीबद्दलचा संदेश ही रनटाइम अवलंबित्वाची समस्या आहे. डिस्ट्रिब्युशनचे नाव पुनरावृत्ती करणारा संदेश पुन्हा ओळख तपासणी आहे, दुसऱ्या ठिकाणी.

डायनॅमिक लिंकरचे दस्तऐवज लायब्ररी शोध कसा चालतो आणि लोडर कुठे शोधतो हे स्पष्ट करते. डिस्ट्रिब्युशन लेबल बदलल्याने त्या शोध मार्गात डिरेक्टरी जोडली जात नाही, म्हणूनच दुसरे अपयश पहिल्याशी असंबंधित वाटते.

डाउनलोड केलेल्या एक्झिक्युटेबलवर ldd सामान्य पहिले पाऊल म्हणून वापरू नका. त्याचे स्वतःचे मॅन्युअल इशारा देते की काही परिस्थितीत ते कार्यक्रम चालवू शकते, आणि अविश्वासनीय इंस्टॉलर चालवणे हेच त्या इशाऱ्याचा विषय असलेली परिस्थिती आहे.

स्ट्रिंग संपादित केल्याने मदत का होत नाही

ऑपरेटिंग सिस्टमची ओळख बनावट करणे म्हणजे मशीनवरील प्रत्येक कार्यक्रम स्वतःला कसे पाहतो ते बदलणे. पॅकेज व्यवस्थापक, समर्थन साधने आणि इतर अनुप्रयोग तीच फाइल वाचतात, आणि एका इंस्टॉलरला समाधान देणारे मूल्य महिन्यांनंतर दुसऱ्या कशालातरी गोंधळात टाकू शकते.

होस्ट लायब्रऱ्या दुसऱ्या डिस्ट्रिब्युशनच्या फाइलांनी बदलणे अधिक वाईट. ते असंबंधित सॉफ्टवेअर तोडू शकते, पॅकेज व्यवस्थापकाला अदृश्य आहे, आणि कोणीही न लिहिणारा देखभाल आराखडा मागते. ते बदल एका प्रतिबंधक इंस्टॉलरने न्याय्य ठरत नाहीत.

तपासणी खरोखर ओळखीचा दोष असेल, तर मेंटेनर तो पुष्टी करू शकतो आणि समर्थित दुरुस्ती सांगू शकतो. दोष नसेल, तर समर्थित मार्ग तुमच्या प्लॅटफॉर्मसाठीचा बिल्ड आहे, आणि स्ट्रिंग संपादित केल्यामुळे ते उत्तर बदलत नाही.

मेंटेनर कारवाई करू शकेल असा अहवाल लिहा

डिस्ट्रिब्युशन आणि प्रकाशन, आर्किटेक्चर, VPN प्रकाशन, नाकारलेली नेमकी अट आणि तिथपर्यंत पोहोचलात तर पहिली रनटाइम त्रुटी नोंदवा. तुम्ही काही बदलले का ते नमूद करा, कारण बदललेल्या सिस्टमवरून आलेला अहवाल वेगळा अहवाल असतो.

मूळ इंस्टॉलर बदलल्याशिवाय ठेवा आणि त्याला चकवण्याऐवजी तपासणीचे वर्णन करा. हाच फरक मेंटेनरला अत्यंत अरुंद ओळख नियम आणि खरी बायनरी सुसंगतता सीमा वेगळी करू देतो, आणि त्या दोन फार वेगळ्या बग आणि दोन फार वेगळ्या दुरुस्त्या आहेत.

तुमचा प्लॅटफॉर्म समर्थित नाही असे उत्तर आले, तर तो उपयुक्त निकाल आहे. कधीही समस्या नसलेल्या ओळख फाइलींवर आणखी एक संध्याकाळ न घालवता समर्थित बिल्ड शोधा असे ते सांगते.