64-बिट सिस्टम पर 32-बिट बाइनरी चलाते समय "नहीं मिला" संदेश प्राप्त करना

Question

मुझे वर्तमान में डेबियन (wheezy / amd64) पर एक अजीब समस्या है।

मैंने एक सर्वर स्थापित करने के लिए एक क्रोकेट बनाया है (मैं इसके बारे में और अधिक विवरण नहीं दे सकता, क्षमा करें)। चलो इसका रास्ता बताते हैं /chr_path/। चीजों को आसान बनाने के लिए, मैंने इस चुरोट को डीबूटस्ट्रैप (मट्ठे / amd64 के साथ) से आरंभ किया है।

चेरोट के अंदर सभी अच्छी तरह से काम करते थे, लेकिन जब मैंने अपने सर्वर की इंस्टॉलर स्क्रिप्ट शुरू की तो मुझे मिला: zsh: Not found /some_path/perl(इंस्टॉलर में कुछ कारणों से एक पर्ल बाइनरी शामिल है)

स्वाभाविक रूप से, मैंने /some_path/स्थान की जाँच की और मुझे "पर्ल" बाइनरी मिला। fileचेरोट पर्यावरण रिटर्न में:

/some_path/perl ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.2.5, not stripped

फ़ाइल मौजूद है, ठीक लगता है, सही अधिकार है। मैं उपयोग कर सकते हैं file, ls, vimइस पर लेकिन जैसे ही मैं कोशिश यह निष्पादित करने के लिए - ./perlउदाहरण के लिए - मैं: zsh: Not found ./perl।

यह स्थिति मेरे लिए काफी समझ में आती है। इसके अलावा:

• मैं त्रुटि प्राप्त किए बिना अन्य बुनियादी बायनेरिज़ (/ बिन / एलएस, ...) को चुरोट में निष्पादित कर सकता हूं
• मुझे अन्य बायनेरिज़ के लिए वही समस्याएं हैं जो परियोजना के साथ आई थीं
• जब मैं बाइनरी को मुख्य रूट ( /chr_path/some_path/perl) से निष्पादित करने का प्रयास करता हूं , तो यह काम करता है।
• मैंने अपनी एक प्रति के साथ बायनेरिज़ में से एक को डालने की कोशिश की है ls। मैंने जाँच की कि पहुँच अधिकार समान थे लेकिन इससे कुछ भी नहीं बदला (एक काम कर रहा था, और दूसरा नहीं था)

Comments

यह "कोई ऐसी फ़ाइल या निर्देशिका नहीं" के रूप में एक ही मुद्दा है Optware स्थापित बायनेरिज़ पर निहित है । ध्यान दें कि आपका पर्ल एक 32-बिट निष्पादन योग्य है। आप 32-बिट रनटाइम सिस्टम ( libc6-i386पैकेज, या ia32-libsयदि आप बहुत सारे पुस्तकालय चाहते हैं) को याद कर रहे हैं।

— गाइल्स

@ गिल्स: बहुत बहुत धन्यवाद! एक योग्यता स्थापित ia32-libs समस्या हल हो गई है !! मैंने देखा था कि पर्ल 32 बिट्स का था, लेकिन चूंकि यह मुख्य सिस्टम (उसी डिस्ट्रिब) पर काम कर रहा था, इसलिए मैंने यह मान लिया था कि यह लिंक नहीं था। दरअसल, मैंने कुछ बिंदु पर मुख्य प्रणाली पर 32-बिट रनटाइम सिस्टम स्थापित किया होगा।

— एलेनहेर

@ गिल्स: मुझे लगता है कि मैं इसे एक डुप्लिकेट प्रश्न के रूप में चिह्नित करने के बजाय संक्षिप्त जवाब के रूप में जोड़ूंगा। पर्यावरण काफी अलग है कि भले ही समस्या समान हो, लोगों को एक या दूसरे को हिट करने की अधिक संभावना है।

— कालेब

@ कालेब हम उस कारण से डुप्लिकेट को नहीं हटाते हैं; खोजकर्ता जो इसे ढूंढते हैं, वह दूसरे पोस्ट के डुप्लिकेट लिंक का अनुसरण करेगा। यदि यह एक ही समस्या यह शायद सिर्फ बंद किया जाना चाहिए है

— माइकल Mrozek

@MichaelMrozek मैंने इस सवाल पर अपना विचार बदल दिया है: जबकि अंतर्निहित मुद्दा एक ही है, ठोस उपाय थोड़ा अलग है (एक मामले में एआरएम एबीआई को मिश्रण नहीं करना, दूसरे में एक amd64 लिनक्स वितरण पर 32-बिट समर्थन को सक्षम करना) । इसलिए मुझे लगता है कि यह सवाल आखिरकार खुला हुआ है।

— गिले

Answer 1

जब आप किसी फ़ाइल को निष्पादित करने में विफल होते हैं, जो "लोडर" पर निर्भर करता है, तो आपको जो त्रुटि मिल सकती है, वह फ़ाइल लोड करने के बजाय लोडर को संदर्भित कर सकती है।

• डायनेमिकली लिंक्ड नेटिव एक्ज़ीक्यूटेबल का लोडर उस सिस्टम का हिस्सा है जो डायनेमिक लाइब्रेरी लोड करने के लिए ज़िम्मेदार है। यह कुछ ऐसा है /lib/ld.soया /lib/ld-linux.so.2, और एक निष्पादन योग्य फ़ाइल होना चाहिए।
• एक स्क्रिप्ट का लोडर शेबंग लाइन पर उल्लिखित प्रोग्राम है, उदाहरण के /bin/shलिए एक स्क्रिप्ट के साथ शुरू होता है #!/bin/sh। (बैश और ज़श इस मामले में "कमांड नहीं मिली" के बजाय "खराब दुभाषिया" संदेश देते हैं।)

त्रुटि संदेश बल्कि भ्रामक संकेत है कि लोडर समस्या है। दुर्भाग्य से, इसे ठीक करना कठिन होगा क्योंकि कर्नेल इंटरफ़ेस में केवल संख्यात्मक त्रुटि कोड की रिपोर्ट करने के लिए जगह है, न कि यह इंगित करने के लिए कि वास्तव में त्रुटि एक अलग फ़ाइल की चिंता करती है। कुछ गोले स्क्रिप्ट के लिए खुद काम करते हैं ( #!स्क्रिप्ट पर लाइन पढ़ना और त्रुटि स्थिति को फिर से काम करना), लेकिन कोई भी जो मैंने देशी बायनेरिज़ के लिए ऐसा करने का प्रयास नहीं देखा है।

lddबायनेरिज़ पर काम नहीं करेगा क्योंकि यह कुछ विशेष पर्यावरण चर को सेट करके और फिर प्रोग्राम को चलाने से काम करता है, जिससे लोडर को काम करने की अनुमति मिलती है। straceकोई भी सार्थक जानकारी प्रदान नहीं करेगा, क्योंकि यह कर्नेल की रिपोर्ट की तुलना में अधिक रिपोर्ट नहीं करेगा, और जैसा कि हमने देखा है कर्नेल सब कुछ नहीं जानता है जो इसे जानता है।

यह स्थिति अक्सर तब उत्पन्न होती है जब आप सही सिस्टम (या सिस्टम के परिवार) और सुपरऑर्किटेक्चर के लिए बाइनरी को चलाने की कोशिश करते हैं लेकिन गलत सबऑर्किटेक्चर। यहां आपके पास एक सिस्टम पर ELF बायनेरी है जो ELF बायनेरिज़ की अपेक्षा करता है, इसलिए कर्नेल उन्हें ठीक लोड करता है। वे एक x86_64 प्रोसेसर पर चलने वाले i386 बायनेरिज़ हैं, इसलिए निर्देश समझ में आता है और कार्यक्रम को उस बिंदु पर ले जाता है जहां वह अपने लोडर की तलाश कर सकता है। लेकिन कार्यक्रम एक 32-बिट प्रोग्राम है (जैसा कि fileआउटपुट इंगित करता है), 32-बिट लोडर की तलाश में है /lib/ld-linux.so.2, और आपने संभवतः केवल चुरोट में 64-बिट लोडर स्थापित किया है /lib64/ld-linux-x86-64.so.2।

आपको चुरोट में 32-बिट रनटाइम सिस्टम स्थापित करने की आवश्यकता है: लोडर, और सभी पुस्तकालयों को कार्यक्रमों की आवश्यकता होती है। डेबियन मट्ज़ी के बाद से, यदि आप i386 और x86_64 दोनों का समर्थन चाहते हैं, तो एक amd64 इंस्टॉलेशन के साथ शुरू करें और मल्टीकार सपोर्ट को सक्रिय करें : dpkg --add-architecture i386फिर से रन करें apt-get updateऔर apt-get install libc6:i386 zlib1g:i386 …(यदि आप डेबियन के पेरेसेंट पैकेज की निर्भरता की सूची उत्पन्न करना चाहते हैं, तो यह देखने के लिए कि पुस्तकालयों की क्या संभावना है जरूरत है, आप उपयोग कर सकते हैं aptitude search -F %p '~Rdepends:^perl$ ~ri386')। आप ia32-libsपैकेज को स्थापित करके आम पुस्तकालयों के संग्रह में खींच सकते हैं (आपको पहले मल्टीकार समर्थन सक्षम करने की आवश्यकता है)। डेबियन am6464 तक मट्ठे पर, 32-बिट लोडर libc6-i386पैकेज में है। आप स्थापित करके 32-बिट पुस्तकालयों का एक बड़ा सेट स्थापित कर सकते हैं ia32-libs।

Comments

क्या यह केवल एक चीज है जो त्रुटि संदेश को ट्रिगर कर सकती है? मैं 32-बिट लाइब्रेरी स्थापित कर चुका हूँ और यहाँ का आउटपुट है,ldd लेकिन मुझे अभी भी वही त्रुटि मिलती है।

— नाथन उस्मान

@ नथनओसमैन शायद unix.stackexchange.com/questions/76490/…

— गाइल्स

मैंने स्थापित करने की कोशिश की, lsb-coreलेकिन वह मदद नहीं करता था। मुझे लगता है कि मैं इसके लिए एक नया प्रश्न खोलना बेहतर समझता हूं।

— नाथन उस्मान

इसके लिए धन्यवाद, आपने अभी-अभी दो दिन सिर खुजलाया। मैंने सोचा था कि सब कुछ सांख्यिकीय रूप से संकलित किया जा रहा है लेकिन यह नहीं था!

— फिन ओलेरी

Answer 2

ldd(1)अपने perlबाइनरी पर चलाएं । अक्सर Not foundफ़ाइल पर स्पष्ट रूप से भ्रमित करने वाली त्रुटि जो स्पष्ट रूप से होती है, क्योंकि प्रोग्राम द्वारा उपयोग किए गए साझा पुस्तकालयों में से एक नहीं मिली है।

इसलिए यह संभव है कि आपका बायोट्री आपके बायनेरिज़ द्वारा आवश्यक साझा पुस्तकालयों के संबंध में अधूरा है।

Comments

वास्तव में मुझे मिलता है: perl is not a dynamic executableजब मैं चुरोट में होता हूं और मुझे बाहर से निर्भरता की सही सूची मिलती है। मैं वर्तमान में जाँच कर रहा हूँ कि क्या कुछ अजीब है, लेकिन मैंने इस प्रकार की कमी से बचने के लिए एक डीबूटस्ट्रैप का उपयोग किया है और पहले से ही बहुत सारे काम कर रहा है (चेरोट सिस्टम में एक पर्ल निष्पादन योग्य है जो अच्छी तरह से चलता है, लेकिन यह एक अलग संस्करण है; हो सकता है कि मैं सिर्फ कुछ ही करूं; प्रतीकात्मक कड़ी?)

— एलेनहेर

सच कहूं, तो मुझे उम्मीद थी कि डेब्यूस्ट्रैप ने पूरी तरह से चेरोट का उत्पादन किया होगा, इसलिए मैं अपने जवाब के बारे में उस संबंध में सही होने की उम्मीद नहीं करूंगा। लेकिन मैं चेरोट समस्या में लापता पुस्तकालय के पार चला गया हूं, इससे पहले कि मैंने सोचा कि अगर मेरा जवाब उड़ जाएगा तो मैं देखूंगा।

— कैम '15:34

सीएफ मुख्य पोस्ट पर गाइल्स पर टिप्पणी: आप सही थे। कुछ परिवाद गायब थे। डीबूटस्ट्रैप का मुख्य लाभ यह है कि मैं समस्या को एक बुनियादी योग्यता के साथ हल कर सकता हूं :)

— एलेनहेर