ldd me dice que mi aplicación "no es un ejecutable dinámico"

17

Tengo una aplicación de 32 bits (llamada uclsyn) que recibí de un profesor de astronomía. Logré ejecutarlo en CentOS hace un año, pero ahora, cuando estoy configurando una nueva máquina virtual CentOS, no se ejecutará y no puedo entender por qué. Sigue volviendo con "Asesinado".

Este es el intercambio en la línea 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

En la máquina que se ejecuta, "ldd ./uclsyn_linux" devuelve una lista completa de dependencias. He encontrado los paquetes que proporcionan estas bibliotecas compartidas, y todos parecen estar instalados.

Paquetes requeridos

  • 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
  • También hay un montón de bibliotecas locales para la aplicación que he verificado y que ya están instaladas.

Mi entorno

CentOS corriendo bajo VirtualBox

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

centos libraries Carl
fuente
1
conjetura: está intentando ejecutar un binario de 32 bits en un sistema operativo de 64 bits sin bibliotecas de 32 bits instaladas.
michas
Es un binario de 32 bits, pero el sistema operativo que instalé es la versión de 32 bits de CentOS. Al menos eso es lo que el comando uname-a me dice que sí.
Carl
3
@Carl Por curiosidad, ¿qué da strace ./uclsynsalida? Eso puede darnos una pista sobre lo que falta primero.
lgeorget
@lgeorget, Devuelve: execve ("./ uclsyn_linux", ["./uclsyn_linux"], [/ * 56 vars * /] <sin terminar ...> +++ asesinado por SIGKILL +++
Carl
@Carl Ok, entonces ni siquiera llega al punto en el que intenta cargar algunas bibliotecas. Nunca he probado antes straceun programa que no esté correctamente vinculado.
lgeorget

Respuestas:

13

Acabo de tener el problema con un binario de 32 bits, la solución fue:

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
fuente
3
¿Cómo descubriste que faltaba esa biblioteca?
yehudahs
1
Esta solución funcionó para mí. +1
FractalSpace
@yehudahs He ejecutado muchas aplicaciones precompiladas de 32 bits en Linux durante bastante tiempo, además de ingeniería inversa, así que recopilé algunas experiencias de resolución de problemas. : D
lama12345
1
bueno, esto funcionó para mí y me estaba rascando la cabeza por lo que estaba haciendo mal
Marvin Effing
1
También funciona para mí: ldd no encontró algo mientras que esto funciona ^^
jy95
8

El error aquí se debió a no tener suficiente RAM en VirtualMachine. La ejecución strace ./programnameindicaba que el programa estaba siendo eliminado justo cuando comenzó a ejecutarse, antes de cargar cualquiera de las bibliotecas. El aumento de la cantidad de RAM disponible aseguró que el programa pudiera funcionar.

Respuestas útiles

Hubo algunas respuestas útiles de otros, a saber, @slm, que proporcionó comandos útiles para comprobar que cada una de las bibliotecas existía, y @lgeorget, que sugirió probar el stracecomando.

Carl
fuente
5

¿Puedes publicar algunas de las bibliotecas a las que enlaza (desde el sistema original)? Es posible que solo necesite instalar algunas bibliotecas faltantes.

Por lo general, en un sistema CentOS, solo se trata de ejecutar un comando yum así:

yum install <package name>

Puede trabajar hacia atrás desde el sistema original así:

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

En esa salida se puede ver en mi copia de /bin/ls, está recogiendo las bibliotecas compartidas .so por ejemplo, por ejemplo librt.so.1, que pasa a estar ubicado aquí: /lib64/librt.so.1.

Sabiendo esto, en el sistema original, puede ejecutar este comando para averiguar qué paquete proporciona esta biblioteca:

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

Entonces se llama el paquete glibc-2.13-2.x86_64. Entonces para instalarlo harías esto:

$ sudo yum install glibc-2.13-2.x86_64
slm
fuente
Muchísimas gracias por la ayuda. Estoy yendo más lejos. He actualizado mi pregunta con más información ahora, si desea actualizar su respuesta con la misma, sería muy apreciada. :)
Carl
¿Usó yum install <package>esos paquetes a los que hizo referencia en su pregunta?
slm
Sí, lo hice. Todos se instalaron, excepto libuuid.i686, que es ahora, pero todavía tengo el mismo problema.
Carl
2

La respuesta está en su pregunta: intenta ejecutar una aplicación que se compiló para GNU / Linux hace un año e intenta ejecutarla con nuevas bibliotecas, que pueden no ser compatibles o no estar disponibles.

En este punto, tienes dos opciones. Si puede volver a compilarlo (lo cual dudo, si entiendo bien su caso), se ejecutará porque se volverá a vincular con bibliotecas compatibles. De lo contrario, podría intentar construir una especie de sandbox, una VM que se ejecute con una versión anterior de las bibliotecas GNU, por ejemplo, para ejecutar la aplicación.

lgeorget
fuente
1
Esto no es correcto. El programa está vinculado estáticamente, no se hará referencia a ninguna biblioteca en el sistema host. Si bien el ABI aún puede causar incompatibilidad, es poco probable entre revoluciones menores del kernel de Linux (suponiendo la misma arquitectura).
ckhan
1
No está estáticamente vinculado, vea la salida de file. Y mensajes como No package xyz foundsugieren que las bibliotecas necesarias ya no están disponibles (al menos, no como estaban, en los mismos paquetes). Es por eso que sugiero reconstruir el programa, si es posible, o ejecutarlo en un sistema en el que se sabía que funcionaba, con bibliotecas antiguas.
lgeorget
Desafortunadamente, la recompilación no es una opción aquí. Lo ejecuté en otro sistema de la misma manera que lo intento aquí, pero por alguna razón, esta vez no me gusta.
Carl
Esto está mal. El cambio de direcciones no importa en absoluto. Las funciones que se eliminan u otras interrupciones de ABI suceden en las revisiones principales de la biblioteca (que son raras), en cuyo caso, obtendrá un error al cargar libfoo2 si no tiene libfoo2 instalado, ya sea que tenga o no libfoo3 instalado.
psusi
Bien, es bueno saberlo. Pensé que cualquier cambio en una biblioteca podría romper el enlace. Actualmente estoy ejecutando un gentoo y, a menudo, tengo que volver a compilar las dependencias inversas cuando actualizo una biblioteca, por lo que no pensé que la vinculación fuera tan resistente a los cambios de la biblioteca.
lgeorget
0

intente readelf -l uclsyn_linux Solicitar intérprete de programa le dirá lo que falta.

netawater
fuente
1
Me encontré readelf -l <file>con un archivo con el mismo lddcomportamiento ( not a dynamic executable), pero no veo nada que indique inmediatamente que falta una biblioteca. Veo Elf file type is EXEC (Executable file), Entry point, Program Headersy Section to Segment mapping. ¿Qué debo buscar exactamente en la salida?
StockB
0

En Arch Linux , si el archivo es elfo de 32 bits, puede instalar lib32-gcc-libs (desde el repositorio multilib) para resolver el problema.

Un tiburón
fuente