ldd uygulamamın "dinamik bir çalıştırılabilir dosya" olmadığını söylüyor

17

Bir astronomi profesöründen aldığım 32 bitlik bir uygulamaya (uclsyn denir) sahibim. Bir yıl önce CentOS üzerinde çalıştırabildim, ancak şimdi yeni bir CentOS VM kurarken çalışmayacak ve nedenini bulamıyorum. "Öldü" ile geri gelmeye devam ediyor.

Bu komut satırındaki değiş tokuş:

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

Çalıştırılan makinede "ldd ./uclsyn_linux" bağımlılıkların bir listesini döndürür. Bu paylaşılan kütüphaneleri sağlayan paketleri buldum ve hepsi yüklü gibi görünüyor.

Paketler gerekli

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
Ayrıca ben kontrol ve zaten yüklü olan uygulama yerel kütüphaneler yığını vardır.

Çevrem

VirtualBox altında çalışan CentOS

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

centos libraries

— Carl
kaynak

1

wild guess: 32-bit kütüphaneler kurulu olmadan 64-bit işletim sisteminde 32-bit ikili çalıştırmaya çalışıyorsunuz.

— michas

32 bitlik bir ikili dosyadır, ancak yüklediğim OS, CentOS'un 32 bit sürümüdür. En azından uname-a komutunun bana evet dediği şey bu mu?

— Carl

3

@Carl Meraktan strace ./uclsynçıktı ne çıkar ? Bu bize ilk olarak eksik olanla ilgili bir ipucu verebilir.

— lgeorget

@lgeorget, Döndürür: execve ("./ uclsyn_linux", ["./uclsyn_linux"], [/ * 56 vars * /] <bitmemiş ...> +++ SIGKILL +++ tarafından öldürüldü

— Carl

@Carl Tamam, bu yüzden bazı kütüphaneleri yüklemeye çalıştığı noktaya bile gitmiyor. Daha önce hiç stracedoğru bağlanmamış bir program denedim .

— lgeorget

13

Ben sadece 32-bit ikili ile sorun vardı, çözüm:

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
kaynak

3

bu lib'in eksik olduğunu nasıl buldun?

— yehudahs

1

Bu çözüm benim için çalıştı. +1

— FractalSpace

@yehudahs Linux üzerinde bir süre önceden derlenmiş 32bit uygulamalar çalıştırdım ve bunları Tersine Mühendislik uyguladım, bu yüzden bazı sorun giderme deneyimleri topladım. : D

— lama12345

1

güzel bu benim için çalıştı yanı sıra ben ne yanlış yapıyordum başımı tırmalamak oldu

— Marvin Effing

1

Benim için de çalışır: ldd bir şey bulamadı, ancak bu çalışıyor ^^

— jy95

8

Buradaki hata, VirtualMachine'da yeterli RAM olmamasından kaynaklandı. Running strace ./programname, herhangi bir kütüphaneyi yüklemeden önce programın çalışmaya başladığı anda öldürüldüğünü gösterdi. Kullanılabilir RAM miktarının artırılması, programın çalışmasını sağlamıştır.

Yararlı tepkiler

Kütüphanelerin her birinin var olup olmadığını kontrol etmek için yararlı komutlar sağlayan @slm ve stracekomutu denemeyi öneren @lgeorget gibi bazı yararlı yanıtlar vardı .

— Carl
kaynak

5

Bağlandığı bazı kütüphaneleri (orijinal sistemden) gönderebilir misiniz? Bazı eksik kütüphaneleri kurmanız gerekebilir.

Tipik olarak bir CentOS sisteminde bu sadece aşağıdaki gibi bir yum komutu çalıştırmakla ilgilidir:

yum install <package name>

Orijinal sistemden şu şekilde geriye doğru çalışabilirsiniz:

$ 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)

Kopyamı nerede çıktısında Gördüğünüz /bin/lsdiyelim örneğin .bu paylaşılan kütüphaneleri toplamaksa, librt.so.1şu adreste olur ki: /lib64/librt.so.1.

Bunu bilerek, orijinal sistemde, hangi kütüphanenin bu kütüphaneyi sağladığını bulmak için bu komutu çalıştırabilirsiniz:

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

Yani paket denir glibc-2.13-2.x86_64. Bu yüzden yüklemek için bunu yaparsınız:

$ sudo yum install glibc-2.13-2.x86_64

— slm
kaynak

Yardımın için çok teşekkürler. Daha ileri gidiyorum. Cevabımı şimdi biraz daha bilgi ile güncelledim, eğer cevabınızı aynı şekilde güncellemek istiyorsanız çok takdir edilecektir. :)

— Carl

Sorunuzda yum install <package>referans verdiğiniz paketleri mi yaptınız ?

— slm

Evet yaptım. Şu anda libuuid.i686 dışında hepsi kuruldu, ama yine de aynı sorunum var.

— Carl

2

Cevap sizin sorunuzda: bir yıl önce GNU / Linux için derlenmiş bir uygulamayı çalıştırmaya çalışıyorsunuz ve onu artık uyumlu veya mevcut olmayan yeni kütüphanelerle çalıştırmaya çalışıyorsunuz.

Bu noktada, iki seçeneğiniz var. Yeniden derleyebiliyorsanız (ki durumunuzu iyi anlarsam şüpheliyim), uyumlu kütüphanelerle yeniden bağlanacağından çalışacaktır. Aksi takdirde, uygulamayı çalıştırmak için örneğin GNU kitaplıklarının eski bir sürümüyle çalışan bir sanal alan olan bir sanal alan oluşturmayı deneyebilirsiniz.

— lgeorget
kaynak

1

Bu doğru değil. Program statik olarak bağlanmıştır, ana bilgisayar sistemindeki hiçbir kitaplığa referans verilmeyecektir. ABI hala uyumsuzluğa neden olsa da, linux çekirdeğinin küçük revizyonları arasında olası değildir (aynı mimariyi varsayarak).

— ckhan

1

Statik olarak bağlı değil, çıktıya bakın file. Ve benzer iletiler No package xyz found, gerekli kitaplıkların artık kullanılamadığını (en azından aynı paketlerde olduğu gibi değil) önerir. Bu nedenle, mümkünse programı yeniden oluşturmanızı veya çalıştığı bilinen bir sistemde eski kütüphanelerle çalıştırmanızı öneririm.

— lgeorget

Maalesef yeniden derleme burada bir seçenek değil. Burada çalıştığım şekilde başka bir sistemde çalıştırabildim, ama bir nedenden dolayı bu sefer hoşlanmıyor.

— Carl

Bu yanlış. Adres değiştirmenin hiç önemi yok. Kaldırılan işlevler veya diğer ABI kesintileri kütüphanenin büyük revizyonlarında gerçekleşir (nadirdir), bu durumda libfoo2 kurulu olmasa da yüklü değilse, libfoo2 yüklü değilse libfoo2 yüklenirken bir hata alırsınız.

— psusi

Tamam, bilmek güzel. Kütüphanedeki herhangi bir değişikliğin bağlantıyı kesebileceğini düşündüm. Şu anda bir gentoo çalıştırıyorum ve genellikle bir kütüphaneyi yükselttiğimde ters bağımlılıkları yeniden derlemem gerekiyor, bu yüzden bağlantıların kütüphane değişikliklerine karşı çok dirençli olduğunu düşünmüyordum.

— lgeorget

0

denemek readelf -l uclsyn_linux program tercüman size eksik ne söyleyecektir.

— netawater
kaynak

1

readelf -l <file>Aynı ldddavranış ( not a dynamic executable) ile bir dosyaya karşı koştu , ama hemen eksik bir kitaplık gösteren bir şey görmüyorum. Anlıyorum Elf file type is EXEC (Executable file), Entry point, Program Headersve Section to Segment mapping. Çıktıda tam olarak ne aramalıyım?

— StockB

0

In Arch Linux dosya 32 bit elf ise, yükleyebilirsiniz lib32-gcc-kütüphanelerini sorunu çözmek için (multilib depodan).

— Bir köpekbalığı
kaynak