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

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