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 ~/mingw64
katalog, 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/as
daje 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/as
daje 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 -l
to:
-rwxr-xr-x 2 ruben users 1506464 11 aug 23:49 /home/ruben/mingw64/bin/x86_64-w64-mingw32-as
Dane wyjściowe objdump -p
to:
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 -v
Ubuntu 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.
Odpowiedzi:
Jeśli uruchomię
ldd -v as
na swoim systemie, otrzymam:Tak, wygląda na to, że te pliki binarne szukają
GLIBC_2.14
symbolu, którego prawdopodobnie brakuje w twoim systemie. Jak zauważył svenx, wygląda na to, że szukamemcpy@@GLIBC_2.14
symbolu. Więcej informacji o tym, dlaczegomemcpy
otrzymano nową wersję, opisano w tym raporcie o błędzie .Zainstalowanie nowej wersji
glibc
systemu docelowego powinno to naprawić. Jeśli chcesz spróbować odbudować plik binarny, aby nadal działał na starej wersjiglibc
, 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ęmemcpy
symbolu, 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:Chociaż
ldd
wiedział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:Nie jestem w 100% pewien, że to działa poprawnie - w moim systemie uruchomienie w
gcc
ten sposób powoduje błąd segmentacji. Ale to co najmniej inny problem.źródło
:(
/lib64
na 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.patchelf
zadziałało.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.2
istnieje, ale w innej lokalizacji/lib64/ld-linux-x86-64.so.2
. Najprostszym sposobem na uruchomienie programów byłoby utworzenie dowiązania symbolicznego:źródło