กำลังเรียกใช้ไฟล์ไบนารี: ไม่พบไฟล์


9

ฉันรู้ว่ามีคำถามที่คล้ายกัน แต่ฉันไม่พบวิธีแก้ปัญหาหรือกรณีนี้ ไบนารีถูกสร้างบน Arch Linux โดยใช้ GCC 4.7 แพคเกจทำงานได้ดีในระบบการสร้าง คำสั่งด้านล่างนี้ถูกดำเนินการเมื่อ:

Linux vbox-ubuntu 3.2.0-29-generic # 46-Ubuntu SMP ศุกร์ 27 ก.ค. 17:03:23 UTC 2012 x86_64 x86_64 x86_64 GNU / Linux

แฟ้มในคำถามตั้งอยู่ที่นี่ มันเป็น Linux-64-bit to Windows 64-bit cross-compiler ไม่ทำการดึงข้อมูลเพื่อ~/ให้มี~/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)

ฉันกำลังสูญเสียอย่างแท้จริง ความช่วยเหลือใด ๆ ที่ชื่นชมมาก

แก้ไข : รายละเอียดเพิ่มเติมบางส่วน: ระบบการสร้างเป็น Arch Linux (ปัจจุบัน glibc 2.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บน Ubuntu 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

ระบบปฏิบัติการอื่นที่ทดสอบคือ Fedora 17 (glibc 2.15) และ Ubuntu 12.04 (eglibc 2.15) เป็นไปตามข้อกำหนดทั้งเวอร์ชันของ zlib และ glibc


มันเป็นแค่ตัวพิมพ์ผิดหรือคุณพยายามเรียกใช้ '~ / mingw64 / x86_64-w64-mingw32 / as' ... มันหายไปในโฟลเดอร์ 'bin'
สามเท่า

@tripledes type และแก้ไขแล้ว
rubenvb

แปลกเพียงแค่พยายามดาวน์โหลดไม่ได้กดปุ่ม ~ และฉันก็จะได้ผลลัพธ์ที่ถูกตรวจสอบ คุณสามารถระบุ ls -l ~ / mingw64 / x86_64-w64-mingw32 / bin / as ได้ไหม
สามเท่า

1
อาจเป็นเวอร์ชัน libc ที่ไม่ตรงกันหรือไม่ ลองเรียกใช้ "objdump -p <path / to / as>" และตรวจสอบส่วน "การอ้างอิงรุ่น" ดูเหมือนว่าจะขึ้นอยู่กับ GLIBC_2.14 ซึ่งถือว่าค่อนข้างใหม่ รุ่นระบบของคุณคืออะไร? "readelf -a <path / to / as> | less" และ grep สำหรับ GLIBC คุณจะเห็นว่ามันใช้ memcpy จาก 2.14 ฉันไม่รู้ว่าทำไมเวอร์ชันจะแตกต่างกันมากระหว่างการเรียกใช้ห้องสมุดที่แตกต่าง
svenx

คำตอบ:


8

ถ้าฉันทำงาน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สัญลักษณ์ซึ่งคุณอาจขาดหายไปในระบบของคุณ สเวนซ์ชี้ให้เห็นดูเหมือนว่ากำลังค้นหาmemcpy@@GLIBC_2.14สัญลักษณ์ ข้อมูลเพิ่มเติมเกี่ยวกับสาเหตุที่memcpyได้รับเวอร์ชันใหม่อธิบายไว้ในรายงานข้อผิดพลาดนี้

การติดตั้งเวอร์ชันใหม่glibcบนระบบเป้าหมายของคุณควรแก้ไข ถ้าคุณต้องการที่จะพยายามที่จะสร้างไบนารีการทำงานยังคงอยู่ในรุ่นเก่าของglibcคุณอาจจะลองเทคนิคอย่างหนึ่งที่แสดงไว้ที่นี่ นอกจากนี้คุณยังสามารถใช้ shim ที่แสดงสัญลักษณ์เฉพาะรุ่นmemcpyที่คุณต้องการ แต่นั่นอาจจะเป็นเรื่องที่ยุ่งยาก


หลังจากอ่านการอัปเดตของคุณ : คุณพูดถูกนั่นไม่ใช่ปัญหาของคุณ แต่ฉันคิดว่าฉันเจอแล้ว: ไบนารีของคุณกำลังร้องขอล่าม/lib/ld-linux-x86-64.so.2ซึ่งไม่มีอยู่ในระบบ Ubuntu 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วิธีนี้จะทำให้การแบ่งกลุ่มผิดพลาด แต่อย่างน้อยก็เป็นปัญหาที่แตกต่าง


1
นั่นคงจะดีถ้าเป็นอย่างนี้ ดูอัปเดต:(
rubenvb

ฉันอัพเดตคำตอบแล้ว
จิมปารีส

ว้าวโอเค ดูดชนิดนี้ ฉันไม่สามารถคิดวิธีที่เหมาะสมในการแก้ไขปัญหานี้ (และสร้างต่อไปบน Arch) คุณมีความคิดที่ยอดเยี่ยมหรือไม่?
rubenvb

1
ไม่ได้จริงๆ Arch เป็นเพียงความงี่เง่า - มาตรฐานระบบไฟล์ของ Heirarchyบอกอย่างชัดเจนว่าไลบรารีควรอยู่ใน/lib64amd64 และ Arch ดูเหมือนจะแก้ไขแหล่ง gcc ด้วยตนเองเพื่อแก้ไขสิ่งนี้ดังนั้นจึงรับประกันความไม่ลงรอยกันกับการกระจาย Linux อื่น ๆ ดูความคิดเห็นของรายงานข้อผิดพลาดนี้เพื่อหาเหตุผลที่แปลกประหลาดของพวกเขา สำหรับฉันนี่จะเป็นสัญญาณเตือนที่ชัดเจนว่าอยู่ห่างจาก Arch Linux
จิมปารีส

1
ที่กล่าวว่าคุณสามารถเปลี่ยนตำแหน่งล่ามใช้patchelf ดูโพสต์นี้สำหรับคนอื่นที่พบปัญหานี้ซึ่งอ้างว่าใช้patchelfงานได้กับพวกเขา
จิมปารีส

0

ปัญหาของคุณเป็นตัวแปรของการรับข้อความ "ไม่พบ" เมื่อรันไบนารีแบบ 32 บิตบนระบบ 64 บิต : คุณมีไฟล์ปฏิบัติการที่กล่าวถึงตัวโหลดแบบไดนามิกที่ไม่ได้อยู่ที่นั่น

ในกรณีของคุณตัวโหลดแบบไดนามิก/lib/ld-linux-x86-64.so.2มีอยู่ แต่ในตำแหน่ง/lib64/ld-linux-x86-64.so.2อื่น วิธีที่ง่ายที่สุดในการทำให้โปรแกรมของคุณใช้งานได้คือการสร้างลิงค์สัญลักษณ์:

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

ดีเนื่องจากเป็นแพคเกจที่มีไว้สำหรับแจกจ่ายซ้ำ symlink ดังกล่าวไม่ได้อยู่ในการควบคุมของฉันจริงๆ ฉันคิดว่าลินุกซ์ไบนารีจะพกพาได้มากกว่านี้ ... เดาสิ
rubenvb
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.