ldd mówi mi, że moja aplikacja „nie jest dynamicznym plikiem wykonywalnym”

17

Mam 32-bitową aplikację (o nazwie uclsyn) otrzymaną od profesora astronomii. Udało mi się uruchomić go w CentOS rok temu, ale teraz, kiedy konfiguruję nową maszynę Wirtualną CentOS, nie będzie działać i nie wiem, dlaczego. Ciągle powraca z „Killed”.

Oto wymiana w wierszu poleceń:

$ ./uclsyn_linux
Killed

$ ldd ./uclsyn_linux
not a dynamic executable

$ file ./uclsyn_linux
uclsyn_linux: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped

Na komputerze, na którym działa, „ldd ./uclsyn_linux” zwraca całą listę zależności. Znalazłem pakiety, które udostępniają te współdzielone biblioteki i wszystkie wydają się być zainstalowane.

Wymagane pakiety

libSM-1.1.0-7.1.el6.i686
libX11-1.3-2.el6.i686
libgcc-4.4.6-3.el6.i386
glibc-2.12-1.47.el6_2.9.i686
libuuid-2.17.2-12.4.el6.i686
libXau-1.0.5-1.el6.i686
Istnieje również mnóstwo bibliotek lokalnych dla aplikacji, które sprawdziłem i są już zainstalowane.

Moje środowisko

CentOS działa pod VirtualBox

uname -a: Linux localhost.localdomain 2.6.32-358.el6.i686 # 1 SMP czw. 21 lutego 12:50:49 UTC 2013 i686 i686 i386 GNU / Linux

centos libraries

— Carl
źródło

1

dzikie zgadywanie: próbujesz uruchomić 32-bitowy plik binarny w 64-bitowym systemie operacyjnym bez zainstalowanych bibliotek 32-bitowych.

— michas

Jest to 32-bitowy plik binarny, ale zainstalowany system operacyjny to 32-bitowa wersja CentOS. Przynajmniej tak mówi polecenie uname-a tak?

— Carl

3

@Carl Co ciekawego wypływa z ciekawości strace ./uclsyn? To może dać nam podpowiedź na temat tego, czego najpierw brakuje.

— lgeorget

@lgeorget, Zwraca: execve ("./ uclsyn_linux", ["./uclsyn_linux"], [/ * 56 vars * /] <niedokończone ...> +++ zabity przez SIGKILL +++

— Carl

@ Carl Ok, więc nawet nie przechodzi do punktu, w którym próbuje załadować niektóre biblioteki. Nigdy wcześniej nie próbowałem, aby straceprogram nie był poprawnie połączony.

— lgeorget

13

Właśnie miałem problem z 32-bitowym plikiem binarnym, rozwiązaniem było:

apt-get install gcc-multilib

$ uname -a
Linux bla 2.6.32-028stab094.3 #1 SMP Thu Sep 22 12:47:37 MSD 2011 x86_64 GNU/Linux

— lama12345
źródło

3

jak odkryłeś, że brakuje tej biblioteki?

— yehudahs,

1

To rozwiązanie działało dla mnie. +1

— FractalSpace 15.01.2015

@yehudahs Od dłuższego czasu uruchomiłem wiele wstępnie skompilowanych 32-bitowych aplikacji na Linuksie oraz ich Inżynieria odwrotna, więc zebrałem trochę problemów z rozwiązywaniem problemów. : D

— lama12345,

1

miło, że to działało dla mnie, a także drapałem się po głowie, co robiłem źle

— Marvin Effing

1

Działa również dla mnie: ldd nie znalazł czegoś, podczas gdy to działa ^^

— jy95

8

Błąd tutaj wynikał z braku wystarczającej ilości pamięci RAM w VirtualMachine. Uruchomienie strace ./programnamewskazywało, że program został zabity w momencie, gdy zaczął działać, przed załadowaniem dowolnej biblioteki. Zwiększenie ilości dostępnej pamięci RAM zapewniło działanie programu.

Przydatne odpowiedzi

Odpowiedzi udzielili inni, a mianowicie @slm, który dostarczył przydatne polecenia, aby sprawdzić, czy każda z bibliotek istnieje, oraz @lgeorget, który sugeruje wypróbowanie stracepolecenia.

— Carl
źródło

5

Czy możesz opublikować niektóre biblioteki, do których prowadzi łącze (z oryginalnego systemu)? Może być konieczne zainstalowanie niektórych brakujących bibliotek.

Zwykle w systemie CentOS wystarczy uruchomić polecenie yum, takie jak:

yum install <package name>

Możesz pracować wstecz od oryginalnego systemu w następujący sposób:

$ ldd /bin/ls
    linux-vdso.so.1 =>  (0x00007fff519ff000)
    libselinux.so.1 => /lib64/libselinux.so.1 (0x00000034e8e00000)
    librt.so.1 => /lib64/librt.so.1 (0x00000034e8a00000)
    libcap.so.2 => /lib64/libcap.so.2 (0x0000003d6fe00000)
    libacl.so.1 => /lib64/libacl.so.1 (0x00000034fae00000)
    libc.so.6 => /lib64/libc.so.6 (0x00000034e7200000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00000034e7a00000)
    /lib64/ld-linux-x86-64.so.2 (0x00000034e6e00000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00000034e7e00000)
    libattr.so.1 => /lib64/libattr.so.1 (0x00000034f7600000)

W tej produkcji można zobaczyć, gdzie moja kopia /bin/lsjest podniesienie współdzielone biblioteki .so na przykład powiedzmy librt.so.1, co dzieje się znaleźć tutaj: /lib64/librt.so.1.

Wiedząc o tym, w oryginalnym systemie, możesz uruchomić to polecenie, aby dowiedzieć się, jaki pakiet udostępnia tę bibliotekę:

$ rpm -qf /lib64/librt.so.1
glibc-2.13-2.x86_64

Tak więc pakiet się nazywa glibc-2.13-2.x86_64. Aby go zainstalować, wykonaj następujące czynności:

$ sudo yum install glibc-2.13-2.x86_64

— slm
źródło

Dziękuję bardzo za pomoc. Idę dalej. Zaktualizowałem moje pytanie o więcej informacji teraz, jeśli chcesz zaktualizować swoją odpowiedź o to samo, byłoby bardzo mile widziane. :)

— Carl

Czy yum install <package>te pakiety, o których wspomniałeś w swoim pytaniu?

— slm

Tak. Wszystkie zostały zainstalowane z wyjątkiem libuuid.i686, który jest teraz, ale nadal mam ten sam problem.

— Carl

2

Odpowiedź jest na twoje pytanie: próbujesz uruchomić aplikację, która została skompilowana dla GNU / Linux rok temu i próbujesz uruchomić ją z nowymi bibliotekami, które mogą już nie być kompatybilne lub dostępne.

W tym momencie masz dwie możliwości. Jeśli możesz go ponownie skompilować (co wątpię, jeśli dobrze rozumiem twój przypadek), uruchomi się, ponieważ zostanie ponownie połączony z kompatybilnymi bibliotekami. W przeciwnym razie możesz spróbować zbudować rodzaj piaskownicy, maszyny wirtualnej działającej na przykład ze starą wersją bibliotek GNU, aby uruchomić aplikację.

— lgeorget
źródło

1

To nie jest poprawne. Program jest statycznie powiązany, nie będzie odwoływać się do bibliotek w systemie hosta. Chociaż ABI może nadal powodować niekompatybilność, jest mało prawdopodobne między drobnymi zmianami jądra Linuxa (przy założeniu tej samej architektury).

— ckhan

1

Nie jest statycznie powiązany, patrz dane wyjściowe z file. A takie komunikaty No package xyz foundsugerują, że potrzebne biblioteki nie są już dostępne (przynajmniej nie tak, jak były w tych samych pakietach). Dlatego sugeruję przebudowanie programu, jeśli jest to możliwe, lub uruchomienie go w systemie, w którym działał, ze starymi bibliotekami.

— lgeorget

Niestety ponowna kompilacja nie jest tutaj opcją. Uruchomiłem go na innym systemie, tak jak próbuję tutaj, ale z jakiegoś powodu tym razem się to nie podoba.

— Carl

To jest źle. Zmiana adresów w ogóle nie ma znaczenia. Funkcje są usuwane lub występują inne przerwy ABI w głównych wersjach biblioteki (które są rzadkie), w takim przypadku wystąpiłby błąd podczas ładowania libfoo2, jeśli nie masz zainstalowanego libfoo2, niezależnie od tego, czy masz zainstalowaną libfoo3.

— psusi

Ok, dobrze wiedzieć. Myślałem, że każda zmiana w bibliotece może przerwać łączenie. Obecnie używam Gentoo i często muszę ponownie kompilować odwrotne zależności podczas aktualizacji biblioteki, więc nie sądziłem, że linkowanie jest tak odporne na zmiany w bibliotece.

— lgeorget

0

Spróbuj readelf -l uclsyn_linux Prośba o interpretację programu powie ci, czego brakuje.

— woda netto
źródło

1

Uruchomiłem readelf -l <file>plik o tym samym lddzachowaniu ( not a dynamic executable), ale nie widzę niczego od razu wskazującego brakującą bibliotekę. Widzę Elf file type is EXEC (Executable file), Entry point, Program Headersi Section to Segment mapping. Czego dokładnie powinienem szukać w wynikach?

— StockB

0

W Arch Linux , jeśli plik jest 32-bitowym elfem, możesz zainstalować lib32-gcc-libs (z repozytorium multilib), aby rozwiązać problem.

— Rekin
źródło