wykonywanie pliku binarnego: nie znaleziono pliku

Wiem, że istnieją podobne pytania, ale nie znalazłem rozwiązania ani tego konkretnego przypadku. Plik binarny został zbudowany na Arch Linux przy użyciu GCC 4.7. Pakiet działa dobrze w systemie kompilacji. Poniższe polecenia zostały wykonane:

Linux vbox-ubuntu 3.2.0-29-generic # 46-Ubuntu SMP Pt 27 lipca 17:03:23 UTC 2012 x86_64 x86_64 x86_64 GNU / Linux

Plik, o którym mowa, znajduje się tutaj . Jest to 64-bitowy kompilator krzyżowy z 64-bitowym systemem Windows. Odznaczenie go ~/daje jeden ~/mingw64katalog, który zawiera wszystko, co potrzebne.

Gdy próbuję uruchomić ~/mingw64/x86_64-w64-mingw32/bin/as, otrzymuję:

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

Bieganie file ~/mingw64/x86_64-w64-mingw32/bin/asdaje mi:

/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

Bieganie ldd ~/mingw64/x86_64-w64-mingw32/bin/asdaje mi:

    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)

Naprawdę jestem zagubiony. Każda pomoc jest mile widziana.

EDYCJA : Kilka dodatkowych szczegółów: System kompilacji to Arch Linux (obecnie glibc 2.16). Dane wyjściowe ls -lto:

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

Dane wyjściowe objdump -pto:

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

Dane wyjściowe ldd -vUbuntu 12.04 to:

    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

Inne testowane systemy operacyjne to Fedora 17 (glibc 2.15) i Ubuntu 12.04 (eglibc 2.15). Zarówno wersja zlib, jak i glibc są spełnione.

— rubenvb
źródło

czy to tylko literówka, czy rzeczywiście próbujesz uruchomić „~ / mingw64 / x86_64-w64-mingw32 / as” ... brakuje folderu „bin”.

— trzykrotnie

@tripledes wpisz i poprawione.

— rubenvb,

dziwne, właśnie próbowałem pobrać, rozpakować pod moim ~ i dostaję oczekiwany wynik. Czy możesz podać ls -l ~ / mingw64 / x86_64-w64-mingw32 / bin / as?

— trzykrotnie

Czy może to być niezgodność wersji libc? Spróbuj uruchomić „objdump -p <ścieżka / do / as>” i sprawdź sekcję „Odwołania do wersji”. Może to wyglądać na zależne od GLIBC_2.14, które można uznać za całkiem nowe. Jaka jest twoja wersja systemu? „readelf -a <ścieżka / do / jako> | mniej” i grep dla GLIBC, zobaczysz, że używa memcpy z 2.14. Nie wiem, dlaczego wersja różni się tak bardzo w różnych wywołaniach biblioteki.

— svenx,

Odpowiedzi:

Jeśli uruchomię ldd -v asna swoim systemie, otrzymam:

./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)

Tak, wygląda na to, że te pliki binarne szukają GLIBC_2.14symbolu, którego prawdopodobnie brakuje w twoim systemie. Jak zauważył svenx, wygląda na to, że szuka memcpy@@GLIBC_2.14symbolu. Więcej informacji o tym, dlaczego memcpyotrzymano nową wersję, opisano w tym raporcie o błędzie .

Zainstalowanie nowej wersji glibcsystemu docelowego powinno to naprawić. Jeśli chcesz spróbować odbudować plik binarny, aby nadal działał na starej wersji glibc, możesz wypróbować sztuczki takie jak tutaj wymienione . Być może mógłbyś sobie poradzić z podkładką, która po prostu zapewnia konkretną wersję memcpysymbolu, której potrzebujesz, ale która może być nieco zuchwała.

Po przeczytaniu aktualizacji : masz rację, to nie był twój problem. Ale myślę, że go znalazłem: Twój plik binarny żąda interpretera /lib/ld-linux-x86-64.so.2, który nie istnieje w systemach Ubuntu 12.04:

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

Chociaż lddwiedziałem, jak go znaleźć /lib64, myślę, że jądro nie wie, że kiedy próbuje uruchomić plik binarny i nie może znaleźć żądanego interpretera pliku. Możesz spróbować uruchomić go ręcznie przez interpretera:

$ 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'.

Nie jestem w 100% pewien, że to działa poprawnie - w moim systemie uruchomienie w gccten sposób powoduje błąd segmentacji. Ale to co najmniej inny problem.

— Jim Paris
źródło

Byłoby miło, gdyby tak było. Zobacz aktualizację:(

— rubenvb,

Zaktualizowałem swoją odpowiedź.

— Jim Paris,

Wow ok. Tego rodzaju bani. Nie mogę wymyślić porządnego sposobu obejścia tego problemu (i budowania na Arch). Czy masz jakieś genialne pomysły?

— rubenvb,

Nie całkiem. Arch jest po prostu głupi - Standard systemu plików Heirarchy wyraźnie mówi, że biblioteki powinny być /lib64na amd64, i najwyraźniej Arch ręcznie łata swoje źródła gcc, aby to zmienić, gwarantując w ten sposób niekompatybilność z każdą inną dystrybucją Linuksa. Zobacz komentarze do tego raportu o błędach z ich dziwnym uzasadnieniem. Dla mnie byłby to wyraźny znak ostrzegawczy, aby trzymać się z dala od Arch Linux.

— Jim Paris,

To powiedziawszy, możesz zmienić lokalizację interpretera za pomocą patchelf . Zobacz ten post dla innej osoby, która napotkała ten problem, która twierdziła, że to patchelfzadziałało.

— Jim Paris,

Problem polega na tym, że pojawia się komunikat „Nie znaleziono” podczas uruchamiania 32-bitowego pliku binarnego w 64-bitowym systemie : masz plik wykonywalny, który wspomina o dynamicznym module ładującym, którego nie ma.

W twoim przypadku dynamiczny moduł ładujący /lib/ld-linux-x86-64.so.2istnieje, ale w innej lokalizacji /lib64/ld-linux-x86-64.so.2. Najprostszym sposobem na uruchomienie programów byłoby utworzenie dowiązania symbolicznego:

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

— Gilles „SO- przestań być zły”
źródło

Cóż, ponieważ jest to pakiet przeznaczony do redystrybucji, takie dowiązanie symboliczne tak naprawdę nie jest pod moją kontrolą. Myślałem, że binaria Linuksa będą bardziej przenośne ... chyba nie.

— rubenvb,