fichier binaire en cours d'exécution: fichier introuvable

9

Je sais qu'il y a des questions similaires, mais je n'ai trouvé aucune solution ni ce cas précis. Le binaire a été construit sur Arch Linux en utilisant son GCC 4.7. Le package fonctionne bien sur le système de génération. Les commandes ci-dessous ont été exécutées sur:

Linux vbox-ubuntu 3.2.0-29-generic # 46-Ubuntu SMP ven 27 juil 17:03:23 UTC 2012 x86_64 x86_64 x86_64 GNU / Linux

Le fichier en question se trouve ici . Il s'agit d'un compilateur croisé Linux 64 bits vers Windows 64 bits. Le décompresser ~/donne un ~/mingw64répertoire unique qui contient tout le nécessaire.

Quand j'essaye de lancer ~/mingw64/x86_64-w64-mingw32/bin/asc'est ce que j'obtiens:

bash: /home/ruben/mingw64/x86_64-w64-mingw32/bin/as: No such file or directory

La course file ~/mingw64/x86_64-w64-mingw32/bin/asme donne:

/home/ruben/mingw64/x86_64-w64-mingw32/bin/as: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x0b8e50955e7919b76967bac042f49c5876804248, not stripped

La course ldd ~/mingw64/x86_64-w64-mingw32/bin/asme donne:

    linux-vdso.so.1 =>  (0x00007fff3e367000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f2ceae7e000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2ceaac1000)
    /lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f2ceb0a8000)

Je suis vraiment perdu. Toute aide est très appréciée.

EDIT : Quelques détails supplémentaires: Le système de construction est Arch Linux (actuellement glibc 2.16). La sortie de ls -lest:

-rwxr-xr-x 2 ruben users 1506464 11 aug 23:49 /home/ruben/mingw64/bin/x86_64-w64-mingw32-as

La sortie de objdump -pest:

Version References:
  required from libz.so.1:
    0x0827e5c0 0x00 05 ZLIB_1.2.0
  required from libc.so.6:
    0x0d696917 0x00 06 GLIBC_2.7
    0x06969194 0x00 04 GLIBC_2.14
    0x0d696913 0x00 03 GLIBC_2.3
    0x09691a75 0x00 02 GLIBC_2.2.5

La sortie de ldd -vsur Ubuntu 12.04 est:

    linux-vdso.so.1 =>  (0x00007fff225ff000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fd525c71000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fd5258b4000)
/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007fd525e9b000)

Version information:
/home/ruben/mingw64/x86_64-w64-mingw32/bin/as:
    libz.so.1 (ZLIB_1.2.0) => /lib/x86_64-linux-gnu/libz.so.1
    libc.so.6 (GLIBC_2.7) => /lib/x86_64-linux-gnu/libc.so.6
    libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6
    libc.so.6 (GLIBC_2.3) => /lib/x86_64-linux-gnu/libc.so.6
    libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6
/lib/x86_64-linux-gnu/libz.so.1:
    libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6
    libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6
    libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6
/lib/x86_64-linux-gnu/libc.so.6:
    ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2
    ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2

Les autres systèmes d'exploitation testés sont Fedora 17 (glibc 2.15) et Ubuntu 12.04 (eglibc 2.15). Les exigences des versions zlib et glibc sont respectées.

ubuntu files compiling binary patchelf rubenvb
la source
est-ce juste une faute de frappe ou essayez-vous d'exécuter «~ / mingw64 / x86_64-w64-mingw32 / as» ... il manque le dossier «bin».
triple
@tripledes type, et corrigé.
rubenvb
bizarre, j'ai juste essayé de télécharger, dégagez sous mon ~ et j'obtiens le résultat attendu. Pourriez-vous fournir un ls -l ~ / mingw64 / x86_64-w64-mingw32 / bin / as?
triple
1
Serait-ce une incompatibilité de version libc? Essayez d'exécuter «objdump -p <path / to / as>» et inspectez la section «Références de version». Il pourrait sembler que cela dépend de GLIBC_2.14, qui pourrait être considéré comme relativement nouveau. Quelle est la version de votre système? "readelf -a <path / to / as> | less" et grep pour GLIBC, vous verrez qu'il utilise memcpy à partir de 2.14. Je ne sais pas pourquoi la version varierait tellement entre les différents appels de bibliothèque.
svenx

Réponses:

8

Si je tourne ldd -v assur mon système, j'obtiens:

./as: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by ./as)
        linux-vdso.so.1 =>  (0x00007fff89ab1000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f1e4c81f000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1e4c498000)
        /lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f1e4ca6d000)

Donc oui, il semble que ces fichiers binaires recherchent un GLIBC_2.14symbole, ce qui vous manque probablement sur votre système. Comme l'a fait remarquer Svenx, il semble qu'il cherche le memcpy@@GLIBC_2.14symbole. Des informations supplémentaires sur les raisons pour lesquelles memcpyune nouvelle version a été fournie sont décrites dans ce rapport de bogue .

L'installation d'une nouvelle version de glibcsur votre système cible devrait le corriger. Si vous souhaitez essayer de reconstruire le binaire pour continuer à fonctionner sur l'ancienne version de glibc, vous pouvez essayer des astuces comme celle répertoriée ici . Vous pouvez également vous débrouiller avec une cale qui fournit simplement la version spécifique du memcpysymbole dont vous avez besoin, mais cela devient un peu hacky.

Après avoir lu votre mise à jour : vous avez raison, ce n'était pas votre problème. Mais je pense que je l'ai trouvé: votre binaire demande l'interpréteur /lib/ld-linux-x86-64.so.2, qui n'existe pas sur les systèmes Ubuntu 12.04:

$ readelf -a ./as | grep interpreter
      [Requesting program interpreter: /lib/ld-linux-x86-64.so.2]

Bien qu'il lddsache le trouver à la /lib64place, je suppose que le noyau ne le sait pas lorsqu'il essaie d'exécuter le binaire et ne peut pas trouver l'interpréteur demandé du fichier. Vous pouvez essayer de l'exécuter manuellement via l'interpréteur:

$ pwd
/home/jim/mingw64/x86_64-w64-mingw32/bin
$ ./as --version
-bash: ./as: No such file or directory
$ /lib64/ld-linux-x86-64.so.2 ./as --version
GNU assembler (rubenvb-4.7.1-1-release) 2.23.51.20120808
Copyright 2012 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `x86_64-w64-mingw32'.

Je ne suis pas sûr à 100% que cela fonctionne correctement - sur mon système, le fonctionnement de gcccette façon donne un défaut de segmentation. Mais c'est au moins un problème différent.

Jim Paris
la source
1
Cela aurait été bien, si c'était le cas. Voir la mise à jour:(
rubenvb
J'ai mis à jour ma réponse.
Jim Paris
Wow OK. Ce genre de suce. Je ne peux pas penser à une façon décente de contourner ce problème (et de continuer à construire sur Arch). Avez-vous des idées brillantes?
rubenvb
1
Pas vraiment. Arch est juste stupide - le Filesystem Heirarchy Standard dit clairement que les bibliothèques devraient être /lib64sur amd64, et apparemment Arch corrige manuellement leurs sources gcc pour changer cela, garantissant ainsi une incompatibilité avec toutes les autres distributions Linux. Voir les commentaires de ce rapport de bogue pour leur raisonnement bizarre. Pour moi, ce serait un signe d'avertissement clair pour rester loin d'Arch Linux.
Jim Paris
1
Cela dit, vous pouvez modifier l'emplacement de l'interpréteur à l'aide de patchelf . Voir ce post pour une autre personne rencontrant ce problème, qui a affirmé que cela patchelffonctionnait pour eux.
Jim Paris
0

Votre problème est une variante du message "Introuvable" lors de l'exécution d'un binaire 32 bits sur un système 64 bits : vous avez un exécutable qui mentionne un chargeur dynamique qui n'est pas là.

Dans votre cas, le chargeur dynamique /lib/ld-linux-x86-64.so.2existe mais à un emplacement différent /lib64/ld-linux-x86-64.so.2. Le moyen le plus simple de faire fonctionner vos programmes serait de créer un lien symbolique:

ln -s ../lib64/ld-linux-x86-64.so.2 /lib/
Gilles 'SO- arrête d'être méchant'
la source
eh bien, comme il s'agit d'un package destiné à être redistribué, un tel lien symbolique n'est pas vraiment sous mon contrôle. Je pensais que les binaires Linux seraient plus portables ... devinez pas.
rubenvb