O ldd me diz que meu aplicativo "não é um executável dinâmico"

17

Eu tenho um aplicativo de 32 bits (chamado uclsyn) que recebi de um professor de astronomia. Eu consegui executá-lo no CentOS há um ano, mas agora, quando estou configurando uma nova VM do CentOS, ela não funciona e não sei por quê. Ele continua voltando com "Killed".

Esta é a troca na linha de comando:

$ ./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 máquina que é executada, "ldd ./uclsyn_linux" retorna uma lista inteira de dependências. Encontrei os pacotes que fornecem essas bibliotecas compartilhadas e todas parecem estar instaladas.

Pacotes necessários

  • 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
  • Há também um monte de bibliotecas locais para o aplicativo que eu verifiquei e já estão instaladas.

Meu ambiente

CentOS em execução no VirtualBox

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

centos libraries Carl
fonte
1
palpite: você está tentando executar um binário de 32 bits em um sistema operacional de 64 bits sem bibliotecas de 32 bits instaladas.
Michas
É um binário de 32 bits, mas o sistema operacional que instalei é a versão de 32 bits do CentOS. Pelo menos é o que o comando uname-a me diz que sim?
Carl
3
@Carl Por curiosidade, o que produz strace ./uclsyn? Isso pode nos dar uma dica sobre o que está faltando primeiro.
Lgeorget
@lgeorget, retorna: execve ("./ uclsyn_linux", ["./uclsyn_linux"], [/ * 56 vars * /] <inacabado ...> +++ morto por SIGKILL +++
Carl
@ Carl Ok, por isso nem chega ao ponto em que tenta carregar algumas bibliotecas. Eu nunca tentei antes de straceum programa não vinculado corretamente.
Lgeorget

Respostas:

13

Eu só tive o problema com uma solução binária de 32 bits:

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
fonte
3
como você descobriu que essa lib estava faltando?
yehudahs
1
Esta solução funcionou para mim. 1
FractalSpace
@yehudahs Eu tenho executado muitos aplicativos pré-compilados de 32 bits no Linux por um bom tempo, além da Engenharia Reversa, então coletei algumas experiências de solução de problemas. : D
lama12345
1
bom isso funcionou para mim, assim como eu estava coçando minha cabeça o que eu estava fazendo de errado
Marvin Effing
1
Funciona também para mim: o ldd não encontrou algo, enquanto isso funciona ^^
jy95
8

O erro aqui ocorreu devido à falta de RAM suficiente no VirtualMachine. A execução strace ./programnameindicava que o programa estava sendo morto exatamente como começou a ser executado, antes de carregar qualquer uma das bibliotecas. Aumentar a quantidade de RAM disponível garantiu que o programa funcionasse.

Respostas úteis

Houve algumas respostas úteis de outras pessoas, como @slm, que forneceu comandos úteis para verificar se cada uma das bibliotecas existia, e @lgeorget, que sugere tentar o stracecomando.

Carl
fonte
5

Você pode postar algumas das bibliotecas às quais ele se vincula (do sistema original)? Você pode precisar instalar algumas bibliotecas ausentes.

Normalmente, em um sistema CentOS, é apenas uma questão de executar um comando yum da seguinte forma:

yum install <package name>

Você pode trabalhar ao contrário do sistema original da seguinte maneira:

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

Nesse saída você pode ver onde a minha cópia /bin/lsestá pegando as bibliotecas compartilhadas .so por exemplo digamos, librt.so.1que acontece a ser localizado aqui: /lib64/librt.so.1.

Sabendo disso, no sistema original, você pode executar este comando para descobrir qual pacote fornece esta biblioteca:

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

Então o pacote é chamado glibc-2.13-2.x86_64. Então, para instalá-lo, você faria o seguinte:

$ sudo yum install glibc-2.13-2.x86_64
slm
fonte
Muito obrigado pela ajuda. Estou indo mais longe. Atualizei minha pergunta com mais algumas informações agora, se você deseja atualizar sua resposta com a mesma, seria muito apreciada. :)
Carl
Você fez yum install <package>aqueles pacotes que você referenciou na sua pergunta?
slm
Sim eu fiz. Todos eles foram instalados, exceto o libuuid.i686, que é agora, mas ainda tenho o mesmo problema.
Carl
2

A resposta está na sua pergunta: você tenta executar um aplicativo que foi compilado para o GNU / Linux há um ano e tenta executá-lo com novas bibliotecas, que podem não ser mais compatíveis ou disponíveis.

Neste ponto, você tem duas opções. Se você puder recompilar (o que duvido, se entendi bem o seu caso), ele será executado porque será vinculado novamente a bibliotecas compatíveis. Caso contrário, você pode tentar criar um tipo de sandbox, uma VM executando com uma versão antiga das bibliotecas GNU, por exemplo, para executar o aplicativo.

lgeorget
fonte
1
Isso não está correto. O programa está vinculado estaticamente, nenhuma biblioteca no sistema host será referenciada. Embora a ABI ainda possa causar incompatibilidade, é improvável entre pequenas rotações do kernel do linux (assumindo a mesma arquitetura).
Ckhan #
1
Não está vinculado estaticamente, veja a saída de file. E mensagens como No package xyz foundsugerem que as bibliotecas necessárias não estão mais disponíveis (pelo menos não do jeito que estavam, nos mesmos pacotes). É por isso que sugiro reconstruir o programa, se possível, ou executá-lo em um sistema em que se sabia que funcionava, com bibliotecas antigas.
Lgeorget
Infelizmente, recompilar não é uma opção aqui. Eu consegui rodar em outro sistema exatamente da mesma maneira que estou tentando aqui, mas por algum motivo, desta vez não gosto.
Carl
Isto está errado. Mudança de endereço não importa. As funções sendo removidas ou outras quebras de ABI acontecem nas principais revisões da biblioteca (que são raras); nesse caso, você receberia um erro ao carregar o libfoo2 se não tiver o libfoo2 instalado, tenha ou não o libfoo3 instalado.
Psusi
OK bom saber. Eu pensei que qualquer alteração em uma biblioteca poderia quebrar a ligação. Atualmente, estou executando um gentoo e geralmente tenho que recompilar as dependências reversas quando atualizo uma biblioteca, então não achei que a vinculação fosse tão resistente às alterações da biblioteca.
Lgeorget
0

tente readelf -l uclsyn_linux Solicitar intérprete de programa informará o que está faltando.

água de neta
fonte
1
Corri readelf -l <file>contra um arquivo com o mesmo lddcomportamento ( not a dynamic executable), mas não vejo nada imediatamente indicando uma biblioteca ausente. Vejo Elf file type is EXEC (Executable file), Entry point, Program Headerse Section to Segment mapping. O que exatamente devo procurar na saída?
StockB
0

No Arch Linux , se o arquivo for elf de 32 bits, você poderá instalar lib32-gcc-libs (do repositório multilib) para resolver o problema.

Um tubarão
fonte