बाइनरी फ़ाइल निष्पादित करना: फ़ाइल नहीं मिली

Question

मुझे पता है कि वहाँ भी ऐसे ही सवाल हैं, लेकिन मुझे कोई हल नहीं मिला है और न ही यह सटीक मामला है। बाइनरी को जीसीसी 4.7 का उपयोग करके आर्क लिनक्स पर बनाया गया था। पैकेज बिल्ड सिस्टम पर ठीक काम करता है। नीचे दिए गए आदेशों को निष्पादित किया गया था:

लिनक्स vbox-ubuntu 3.2.0-29-जेनेरिक # 46-उबंटू एसएमपी शुक्र जुलाई 27 17:03:23 UTC 2012 x86_64 x86_64 x86_64 GNU / Linux

प्रश्न में फ़ाइल यहाँ स्थित है । यह लिनक्स 64-बिट से विंडोज 64-बिट क्रॉस-कंपाइलर है। यह ~/एक एकल ~/mingw64निर्देशिका प्रदान करने के लिए असत्य है , जिसमें आवश्यक सब कुछ शामिल है।

जब मैं इसे चलाने की कोशिश ~/mingw64/x86_64-w64-mingw32/bin/asकरता हूं तो मुझे यही मिलता है:

bash: /home/ruben/mingw64/x86_64-w64-mingw32/bin/as: No such file or directory

दौड़ना file ~/mingw64/x86_64-w64-mingw32/bin/asमुझे देता है:

/home/ruben/mingw64/x86_64-w64-mingw32/bin/as: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x0b8e50955e7919b76967bac042f49c5876804248, not stripped

दौड़ना ldd ~/mingw64/x86_64-w64-mingw32/bin/asमुझे देता है:

    linux-vdso.so.1 =>  (0x00007fff3e367000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f2ceae7e000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2ceaac1000)
    /lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f2ceb0a8000)

मैं वास्तव में एक नुकसान में हूं। किसी भी प्रकार की मदद की बेहद सराहना की जाती है।

संपादित करें : कुछ और विवरण: बिल्ड सिस्टम आर्क लिनक्स (वर्तमान में 2.16 glibc) है। का आउटपुट ls -lहै:

-rwxr-xr-x 2 ruben users 1506464 11 aug 23:49 /home/ruben/mingw64/bin/x86_64-w64-mingw32-as

का आउटपुट objdump -pहै:

Version References:
  required from libz.so.1:
    0x0827e5c0 0x00 05 ZLIB_1.2.0
  required from libc.so.6:
    0x0d696917 0x00 06 GLIBC_2.7
    0x06969194 0x00 04 GLIBC_2.14
    0x0d696913 0x00 03 GLIBC_2.3
    0x09691a75 0x00 02 GLIBC_2.2.5

ldd -vUbuntu 12.04 पर आउटपुट है:

    linux-vdso.so.1 =>  (0x00007fff225ff000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fd525c71000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fd5258b4000)
/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007fd525e9b000)

Version information:
/home/ruben/mingw64/x86_64-w64-mingw32/bin/as:
    libz.so.1 (ZLIB_1.2.0) => /lib/x86_64-linux-gnu/libz.so.1
    libc.so.6 (GLIBC_2.7) => /lib/x86_64-linux-gnu/libc.so.6
    libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6
    libc.so.6 (GLIBC_2.3) => /lib/x86_64-linux-gnu/libc.so.6
    libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6
/lib/x86_64-linux-gnu/libz.so.1:
    libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6
    libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6
    libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6
/lib/x86_64-linux-gnu/libc.so.6:
    ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2
    ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2

परीक्षण किए गए अन्य OSes Fedora 17 (glibc 2.15) और Ubuntu 12.04 (eglibc 2.15) हैं। दोनों zlib और glibc संस्करण आवश्यकताओं को पूरा किया जाता है।

Comments

क्या यह सिर्फ एक टाइपो है या आप वास्तव में '~ / mingw64 / x86_64-w64-mingw32 / as' चलाने की कोशिश कर रहे हैं ... यह 'बिन' फ़ोल्डर को याद कर रहा है।

— तिगुना

@ टाइप किए गए प्रकार, और सही किए गए।

— रुबेंवब

अजीब, बस डाउनलोड करने की कोशिश की, मेरे ~ के तहत अनार और मैं प्राप्त परिणाम प्राप्त करता हूं। क्या आप एक ls -l ~ / mingw64 / x86_64-w64-mingw32 / bin / as प्रदान कर सकते हैं?

— tripledes

यह एक libc संस्करण बेमेल हो सकता है? "Objdump -p <path / to / as" चलाने का प्रयास करें और "संस्करण संदर्भ" अनुभाग का निरीक्षण करें। ऐसा लग सकता है कि यह GLIBC_2.14 पर निर्भर करता है, जिसे काफी नया माना जा सकता है। आपका सिस्टम संस्करण क्या है? "readelf -a <path / to / as> | less" और GLIBC के लिए grep, आप देखेंगे कि यह 2.14 से मेमकी का उपयोग कर रहा है। मुझे नहीं पता कि विभिन्न लाइब्रेरी कॉल के बीच संस्करण इतना भिन्न क्यों होगा।

— svenx

Answer 1

अगर मैं ldd -v asअपने सिस्टम पर चलता हूं, तो मुझे मिलता है:

./as: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by ./as)
        linux-vdso.so.1 =>  (0x00007fff89ab1000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f1e4c81f000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1e4c498000)
        /lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f1e4ca6d000)

तो हाँ, ऐसा लगता है कि ये बायनेरिज़ एक GLIBC_2.14प्रतीक की तलाश कर रहे हैं, जिसे आप संभवतः अपने सिस्टम पर याद कर रहे हैं। जैसा कि svenx ने बताया है, ऐसा लगता है कि यह memcpy@@GLIBC_2.14प्रतीक की खोज कर रहा है । इस बग रिपोर्ट मेंmemcpy नया संस्करण क्यों दिया गया , इस पर कुछ और जानकारी दी गई है ।

glibcअपने लक्ष्य प्रणाली पर एक नया संस्करण स्थापित करके इसे ठीक करना चाहिए। यदि आप बाइनरी के पुनर्निर्माण के लिए अभी भी पुराने संस्करण पर काम करने की कोशिश करना चाहते हैं glibc, तो आप यहाँ सूचीबद्ध की तरह ट्रिक्स आज़मा सकते हैं । तुम भी शायद एक शिम के साथ मिल सकते हैं जो सिर्फ उस memcpyप्रतीक का विशिष्ट संस्करण प्रदान करता है जिसकी आपको आवश्यकता होती है, लेकिन वह थोड़ा सा हैक हो जाता है।

---

आपका अपडेट पढ़ने के बाद : आप सही कह रहे हैं, यह आपकी समस्या नहीं थी। लेकिन मुझे लगता है कि मैंने यह पाया है: आपका बाइनरी दुभाषिया से अनुरोध कर रहा है /lib/ld-linux-x86-64.so.2, जो उबंटू 12.04 सिस्टम पर मौजूद नहीं है:

$ readelf -a ./as | grep interpreter
      [Requesting program interpreter: /lib/ld-linux-x86-64.so.2]

जबकि इसके बजाय lddइसे खोजने के लिए /lib64, मुझे लगता है कि कर्नेल को नहीं पता है कि जब यह बाइनरी को चलाने की कोशिश करता है और फ़ाइल के अनुरोधित दुभाषिया को नहीं ढूंढ सकता है। आप मैन्युअल रूप से दुभाषिया के माध्यम से इसे चलाने की कोशिश कर सकते हैं:

$ pwd
/home/jim/mingw64/x86_64-w64-mingw32/bin
$ ./as --version
-bash: ./as: No such file or directory
$ /lib64/ld-linux-x86-64.so.2 ./as --version
GNU assembler (rubenvb-4.7.1-1-release) 2.23.51.20120808
Copyright 2012 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `x86_64-w64-mingw32'.

मैं 100% निश्चित नहीं हूं कि यह सही ढंग से काम कर रहा है - मेरे सिस्टम पर, gccइस तरह से दौड़ना एक विभाजन दोष देता है। लेकिन यह कम से कम एक अलग समस्या है।

Comments

अगर ऐसा होता तो अच्छा होता। अद्यतन देखें:(

— rubenvb

मैंने अपना उत्तर अपडेट कर दिया है।

— जिम पेरिस

वाह ठीक है। इस तरह के बेकार है। मैं इस समस्या के आसपास काम करने के लिए एक अच्छा तरीका नहीं सोच सकता (और आर्क पर निर्माण करना)। क्या आपके पास कोई शानदार विचार है?

— रुबनेव

ज़रुरी नहीं। आर्क सिर्फ बेवकूफ़ बनाया जा रहा है - फाइलसिस्टम हेइरार्की स्टैंडर्ड स्पष्ट रूप से कहता है कि पुस्तकालयों को /lib64amd64 पर होना चाहिए , और जाहिर तौर पर आर्क ने इसे बदलने के लिए अपने gcc स्रोतों को मैन्युअल रूप से पैच किया है, जिससे हर दूसरे लिनक्स वितरण के साथ असंगति की गारंटी मिलती है। इस विचित्र रिपोर्ट की टिप्पणियों को उनके विचित्र तर्क के लिए देखें। मेरे लिए, यह आर्क लिनक्स से दूर रहने के लिए एक स्पष्ट चेतावनी संकेत होगा।

— जिम पेरिस

उस ने कहा, आप patchelf का उपयोग करके दुभाषिया स्थान को बदल सकते हैं । इस समस्या में चल रहे एक अन्य व्यक्ति के लिए यह पोस्ट देखें , जिन्होंने दावा किया कि patchelfउनके लिए काम किया है।

— जिम पेरिस

Answer 2

आपकी समस्या 64-बिट सिस्टम पर 32-बिट बाइनरी को चलाने पर "नहीं मिला" संदेश प्राप्त करने का एक प्रकार है : आपके पास एक निष्पादन योग्य है जो एक गतिशील लोडर का उल्लेख करता है जो वहां नहीं है।

आपके मामले में, डायनेमिक लोडर /lib/ld-linux-x86-64.so.2मौजूद है लेकिन एक अलग स्थान पर /lib64/ld-linux-x86-64.so.2। अपने कार्यक्रमों को काम करने का सबसे सरल तरीका एक प्रतीकात्मक लिंक बनाना होगा:

ln -s ../lib64/ld-linux-x86-64.so.2 /lib/

Comments

ठीक है, क्योंकि यह पुनर्वितरण के लिए एक पैकेज है, इस तरह का एक सिमिलिंक वास्तव में मेरे नियंत्रण में नहीं है। मैंने सोचा कि लिनक्स बायनेरी अधिक पोर्टेबल होगा ... अनुमान नहीं।

— रुबनेव