ldd me dit que mon application n'est «pas un exécutable dynamique»


17

J'ai une application 32 bits (appelée uclsyn) que j'ai reçue d'un professeur d'astronomie. J'ai réussi à le faire fonctionner sur CentOS il y a un an, mais maintenant, lorsque je configure une nouvelle machine virtuelle CentOS, il ne fonctionnera pas et je ne peux pas comprendre pourquoi. Il revient sans cesse avec "Killed".

C'est l'échange sur la ligne de commande:

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

Sur la machine qui s'exécute, "ldd ./uclsyn_linux" retourne toute une liste de dépendances. J'ai trouvé les packages qui fournissent ces bibliothèques partagées, et ils semblent tous être installés.

Forfaits requis

  • 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
  • Il y a aussi un tas de bibliothèques locales à l'application que j'ai vérifié et qui sont déjà installées.

Mon environnement

CentOS fonctionnant sous VirtualBox

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


1
conjecture sauvage: vous essayez d'exécuter un binaire 32 bits sur un système d'exploitation 64 bits sans bibliothèques 32 bits installées.
michas

Il s'agit d'un binaire 32 bits, mais le système d'exploitation que j'ai installé est la version 32 bits de CentOS. Du moins, c'est ce que la commande uname-a me dit oui?
Carl

3
@Carl Par curiosité, qu'est-ce que la strace ./uclsynsortie? Cela peut nous donner une idée de ce qui manque en premier.
lgeorget

@lgeorget, il renvoie: execve ("./ uclsyn_linux", ["./uclsyn_linux"], [/ * 56 vars * /] <inachevé ...> +++ tué par SIGKILL +++
Carl

@Carl Ok, donc il ne va même pas au point où il essaie de charger certaines bibliothèques. Je n'ai jamais essayé auparavant straceun programme qui n'était pas correctement lié.
lgeorget

Réponses:


13

Je viens d'avoir le problème avec un binaire 32 bits, la solution était:

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

3
comment avez-vous découvert que cette bibliothèque manquait?
yehudahs

1
Cette solution a fonctionné pour moi. +1
FractalSpace

@yehudahs J'ai exécuté un bon nombre d'applications précompilées 32 bits sur Linux pendant un certain temps, ainsi que la rétro-ingénierie, donc j'ai collecté des expériences de dépannage. : D
lama12345

1
agréable, cela a fonctionné pour moi aussi bien que je me grattais la tête ce que je faisais mal
Marvin Effing

1
Fonctionne aussi pour moi: ldd n'a pas trouvé quelque chose alors que cela fonctionne ^^
jy95

8

L'erreur ici était due à un manque de RAM sur la VirtualMachine. Fonctionnementstrace ./programname indiqué que le programme était en cours de suppression au moment où il a commencé à s'exécuter, avant de charger l'une des bibliothèques. L'augmentation de la quantité de RAM disponible a assuré le fonctionnement du programme.

Réponses utiles

Il y a eu quelques réponses utiles d'autres à savoir @slm qui a fourni des commandes utiles pour vérifier que chacune des bibliothèques existait, et @lgeorget qui a suggéré d'essayer la stracecommande.


5

Pouvez-vous publier certaines des bibliothèques auxquelles il est lié (à partir du système d'origine)? Vous devrez peut-être simplement installer certaines bibliothèques manquantes.

Généralement, sur un système CentOS, il suffit d'exécuter une commande yum comme ceci:

yum install <package name>

Vous pouvez travailler à l'envers à partir du système d'origine comme ceci:

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

Dans cette sortie , vous pouvez voir où ma copie /bin/lsest ramasser les bibliothèques partagées .donc par exemple de dire, librt.so.1qui se trouve être situé ici: /lib64/librt.so.1.

Sachant cela, sur le système d'origine, vous pouvez exécuter cette commande pour déterminer quel package fournit cette bibliothèque:

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

Le package est donc appelé glibc-2.13-2.x86_64. Donc, pour l'installer, vous feriez ceci:

$ sudo yum install glibc-2.13-2.x86_64

Merci beaucoup pour l'aide. Je vais plus loin. J'ai mis à jour ma question avec plus d'informations maintenant, si vous souhaitez mettre à jour votre réponse avec la même chose, ce serait très apprécié. :)
Carl

Avez-vous yum install <package>ces paquets auxquels vous avez fait référence dans votre question?
slm

Oui je l'ai fait. Ils ont tous été installés à l'exception de libuuid.i686 qui est maintenant, mais j'ai toujours le même problème.
Carl

2

La réponse est dans votre question: vous essayez d'exécuter une application qui a été compilée pour GNU / Linux il y a un an et vous essayez de l'exécuter avec de nouvelles bibliothèques, qui peuvent ne plus être compatibles ou disponibles.

À ce stade, vous avez deux choix. Si vous pouvez le recompiler (ce dont je doute, si je comprends bien votre cas), il fonctionnera car il sera relié avec des bibliothèques compatibles. Sinon, vous pourriez essayer de construire une sorte de sandbox, une VM fonctionnant avec une ancienne version des bibliothèques GNU par exemple, pour exécuter l'application dans.


1
Ce n'est pas correct. Le programme est lié statiquement, aucune bibliothèque sur le système hôte ne sera référencée. Bien que l'ABI puisse toujours provoquer une incompatibilité, il est peu probable entre des révolutions mineures du noyau linux (en supposant la même architecture).
ckhan

1
Ce n'est pas lié statiquement, voir la sortie de file. Et des messages comme No package xyz foundsuggèrent que les bibliothèques nécessaires ne sont plus disponibles (du moins, pas comme elles l'étaient, dans les mêmes packages). C'est pourquoi je suggère de reconstruire le programme, si c'est possible, ou de l'exécuter dans un système dans lequel il était connu de fonctionner, avec d'anciennes bibliothèques.
lgeorget

Malheureusement, la recompilation n'est pas une option ici. Je l'ai fait fonctionner sur un autre système de la même manière que j'essaie ici, mais pour une raison quelconque, cette fois, il ne l'aime pas.
Carl

C'est faux. La modification des adresses n'a pas d'importance du tout. Les fonctions supprimées ou d'autres interruptions ABI se produisent lors des révisions majeures de la bibliothèque (qui sont rares), auquel cas, vous obtiendrez une erreur lors du chargement de libfoo2 si vous n'avez pas installé libfoo2, que vous ayez ou non libfoo3 installé.
psusi

OK bon à savoir. Je pensais que tout changement dans une bibliothèque pourrait rompre la liaison. J'exécute actuellement un gentoo et je dois souvent recompiler les dépendances inverses lorsque je mets à niveau une bibliothèque, donc je ne pensais pas que la liaison était si résistante aux changements de bibliothèque.
lgeorget

0

essayez readelf -l uclsyn_linux Demander l'interpréteur de programme vous dira ce que vous manquez.


1
J'ai couru readelf -l <file>contre un fichier avec le même lddcomportement ( not a dynamic executable), mais je ne vois rien indiquant immédiatement une bibliothèque manquante. Je vois Elf file type is EXEC (Executable file), Entry point, Program Headerset Section to Segment mapping. Que dois-je rechercher exactement dans la sortie?
StockB

0

Dans Arch Linux , si le fichier est un elfe 32 bits, vous pouvez installer lib32-gcc-libs (à partir du référentiel multilib) pour résoudre le problème.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.