বাইনারি ফাইল কার্যকর করা হচ্ছে: ফাইল পাওয়া যায় নি

Question

আমি জানি এখানেও একই ধরণের প্রশ্ন রয়েছে তবে আমি এর সমাধান খুঁজে পাইনি বা এই সঠিক কেসটিও পাই নি। বাইনারিটি আর্চ লিনাক্স এর জিসিসি 4.7 ব্যবহার করে নির্মিত হয়েছিল। প্যাকেজটি বিল্ড সিস্টেমে সূক্ষ্মভাবে কাজ করে। নীচের কমান্ডগুলি এখানে কার্যকর করা হয়েছিল:

লিনাক্স ভিবক্স-উবুন্টু 3.2.0-29-জেনেরিক # 46-উবুন্টু এসএমপি শুক্র জুলাই 27 17:03:23 ইউটিসি 2012 x86_64 x86_64 x86_64 জিএনইউ / লিনাক্স

প্রশ্নযুক্ত ফাইলটি এখানে অবস্থিত । এটি একটি লিনাক্স 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)

আমি সত্যিই একটি ক্ষতি হয়। কোন সাহায্যের অনেক প্রশংসা করা হয়।

সম্পাদনা : আরও বিশদ: বিল্ড সিস্টেমটি আর্চ লিনাক্স (বর্তমানে গ্লিবসি ২.১16)। এর ফলাফল 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 -vউবুন্টু 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

পরীক্ষিত অন্যান্য ওএসগুলি হলেন ফেডোরা 17 (গ্লিবসি 2.15) এবং উবুন্টু 12.04 (eglibc 2.15)। উভয় zlib এবং glibc সংস্করণ প্রয়োজনীয়তা পূরণ করা হয়।

Comments

এটি কি কেবল একটি টাইপো বা আপনি '~ / mingw64 / x86_64-w64-mingw32 / হিসাবে' চালানোর চেষ্টা করছেন ... এটি 'বিন' ফোল্ডারটি হারিয়েছে।

— তিনগুণ

@ ট্রাইপ্লেডগুলি টাইপ করুন এবং সংশোধন করেছেন।

— রুবেনবিবি

অদ্ভুত, কেবল ডাউনলোড করার চেষ্টা করেছি, আমার under এর অধীনে এবং আমি এক্সপেক্টেড রেজাল্ট পেয়েছি। আপনি কি একটি ls -l l / mingw64 / x86_64-w64-mingw32 / বিন / হিসাবে সরবরাহ করতে পারেন?

— 11:14

এটি একটি libc সংস্করণ মেলে না? "Objdump -p <पथ / to / as>" চালানোর চেষ্টা করুন এবং "সংস্করণ রেফারেন্স" বিভাগটি পরীক্ষা করুন। দেখে মনে হচ্ছে এটি GLIBC_2.14 এর উপর নির্ভর করে যা মোটামুটি নতুন হিসাবে বিবেচিত হতে পারে। আপনার সিস্টেম সংস্করণ কি? "রিডফেল -এ <পথ / to / হিসাবে> | কম" এবং জি এল এল বি সি-র জন্য গ্রেপ, আপনি দেখতে পাবেন যে এটি ২.১৪ থেকে মেমকি ব্যবহার করছে। আমি জানি না কেন বিভিন্ন লাইব্রেরি কলগুলির মধ্যে সংস্করণটি এত বেশি পৃথক হবে।

— 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

এটাই যদি হত তবে ভাল হত। আপডেট দেখুন:(

— রুবেভভ

আমি আমার উত্তর আপডেট করেছি।

— জিম প্যারিস

ওহ, ঠিক আছে. এই ধরনের স্তন্যপান। আমি এই সমস্যাটি ঘিরে কাজ করার কোনও শালীন উপায় সম্পর্কে ভাবতে পারি না (এবং আর্চ তৈরি করে রাখি)। আপনার কি কোনও উজ্জ্বল ধারণা আছে?

— রুবেনবিবি

আসলে তা না. আর্চটি কেবল বোকা হয়ে যাচ্ছে - ফাইল সিস্টেম হেরার্চি স্ট্যান্ডার্ড স্পষ্টভাবে বলেছে যে লাইব্রেরিগুলি /lib64amd64 থাকা উচিত এবং দৃশ্যত আর্চ ম্যানুয়ালি তাদের জিসিসি উত্সগুলিকে এটি পরিবর্তন করতে প্যাচ করে, এর ফলে সেখানে প্রতিটি অন্যান্য লিনাক্স বিতরণে অসম্পূর্ণতার গ্যারান্টি দেয় । তাদের উদ্ভট যুক্তির জন্য এই বাগের প্রতিবেদনের মন্তব্যগুলি দেখুন । আমার কাছে এটি আর্চ লিনাক্স থেকে দূরে থাকার জন্য একটি স্পষ্ট সতর্কতা চিহ্ন sign

— জিম প্যারিস 21

এটি বলেছিল, আপনি প্যাচেলফ ব্যবহার করে দোভাষী স্থান পরিবর্তন করতে পারেন । এই সমস্যায় পড়ে অন্য একজনের জন্য এই পোস্টটি দেখুন , যারা দাবি করেছেন যে patchelfতাদের পক্ষে কাজ করেছে।

— জিম প্যারিস

Answer 2

আপনার সমস্যা ৪-বিট সিস্টেমে 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

ঠিক আছে, এটি পুনরায় বিতরণের জন্য বোঝানো একটি প্যাকেজ হিসাবে, এই জাতীয় সিমলিংকটি আসলে আমার নিয়ন্ত্রণে নেই। আমি ভেবেছিলাম লিনাক্স বাইনারিগুলি আরও বহনযোগ্য হবে ... অনুমান করবেন না।

— রুবেনভবি