ejecutando archivo binario: archivo no encontrado

Sé que hay preguntas similares por ahí, pero no he encontrado una solución ni este caso exacto. El binario fue construido en Arch Linux usando su GCC 4.7. El paquete funciona bien en el sistema de compilación. Los siguientes comandos se ejecutaron en:

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

El archivo en cuestión se encuentra aquí . Es un compilador cruzado de Linux de 64 bits a Windows de 64 bits. Desentrañarlo ~/proporciona un único ~/mingw64directorio que contiene todo lo necesario.

Cuando intento ejecutar ~/mingw64/x86_64-w64-mingw32/bin/asesto es lo que obtengo:

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

Correr file ~/mingw64/x86_64-w64-mingw32/bin/asme da:

/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

Correr ldd ~/mingw64/x86_64-w64-mingw32/bin/asme da:

    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)

Estoy realmente perdido. Cualquier ayuda es muy apreciada.

EDITAR : Algunos detalles más: El sistema de compilación es Arch Linux (actualmente glibc 2.16). La salida de ls -les:

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

La salida de objdump -pes:

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 salida de ldd -vUbuntu 12.04 es:

    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

Los otros sistemas operativos probados son Fedora 17 (glibc 2.15) y Ubuntu 12.04 (eglibc 2.15). Se cumplen los requisitos de la versión zlib y glibc.

— rubenvb
fuente

¿es solo un error tipográfico o está intentando ejecutar '~ / mingw64 / x86_64-w64-mingw32 / as'? Falta la carpeta 'bin'.

— tripledes

tipo @tripledes, y corregido.

— rubenvb

raro, solo intenté descargar, descomprimir bajo mi ~ y obtengo el resultado detectado. ¿Podría proporcionar un ls -l ~ / mingw64 / x86_64-w64-mingw32 / bin / as?

— tripledes

¿Podría ser una versión de libc que no coincide? Intente ejecutar "objdump -p <ruta / a / as>" e inspeccione la sección "Referencias de versión". Podría parecer que depende de GLIBC_2.14, que podría considerarse bastante nuevo. ¿Cuál es la versión de tu sistema? "readelf -a <path / to / as> | less" y grep para GLIBC, verá que está usando memcpy desde 2.14. No sé por qué la versión variará tanto entre diferentes llamadas a la biblioteca.

— svenx

Respuestas:

Si ejecuto ldd -v asen mi sistema, obtengo:

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

Entonces, sí, parece que estos binarios están buscando un GLIBC_2.14símbolo, que presumiblemente te falta en tu sistema. Como señaló Svenx, parece que está buscando el memcpy@@GLIBC_2.14símbolo. En este informe de errormemcpy se describe más información sobre por qué se le dio una nueva versión .

Instalar una nueva versión de glibcen su sistema de destino debería solucionarlo. Si desea intentar reconstruir el binario para que siga funcionando en la versión anterior glibc, puede probar trucos como el que se enumera aquí . También podría pasar con una cuña que solo proporciona la versión específica del memcpysímbolo que necesita, pero que se vuelve un poco hacky.

Después de leer su actualización : tiene razón, ese no era su problema. Pero creo que lo he encontrado: su binario está solicitando el intérprete /lib/ld-linux-x86-64.so.2, que no existe en los sistemas Ubuntu 12.04:

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

Si bien lddsabía que debía encontrarlo en su /lib64lugar, supongo que el núcleo no lo sabe cuando intenta ejecutar el binario y no puede encontrar el intérprete solicitado del archivo. Puede intentar simplemente ejecutarlo a través del intérprete manualmente:

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

No estoy 100% seguro de que esto funcione correctamente: en mi sistema, ejecutarlo de gccesta manera da un error de segmentación. Pero ese es al menos un problema diferente.

— Jim Paris
fuente

Eso hubiera sido bueno, si este fuera el caso. Ver actualización:(

— rubenvb

He actualizado mi respuesta.

— Jim Paris

Wow, esta bién. Este tipo de apesta. No puedo pensar en una forma decente para solucionar este problema (y seguir construyendo en Arch). ¿Tienes alguna idea brillante?

— rubenvb

Realmente no. Arch simplemente está siendo estúpido: el estándar de jerarquía del sistema de archivos dice claramente que las bibliotecas deben estar en /lib64amd64, y aparentemente Arch parchea manualmente sus fuentes gcc para cambiar esto, garantizando así la incompatibilidad con cualquier otra distribución de Linux. Consulte los comentarios de este informe de errores para conocer su extraño razonamiento. Para mí, esta sería una clara señal de advertencia para mantenerse alejado de Arch Linux.

— Jim Paris

Dicho esto, puede cambiar la ubicación del intérprete usando patchelf . Vea esta publicación para otra persona que se encuentra con este problema, quien afirmó que patchelffuncionó para ellos.

— Jim Paris

Su problema es una variante del mensaje "No encontrado" al ejecutar un binario de 32 bits en un sistema de 64 bits : tiene un ejecutable que menciona un cargador dinámico que no está allí.

En su caso, el cargador dinámico /lib/ld-linux-x86-64.so.2existe pero en una ubicación diferente /lib64/ld-linux-x86-64.so.2. La forma más sencilla de hacer que sus programas funcionen sería crear un enlace simbólico:

ln -s ../lib64/ld-linux-x86-64.so.2 /lib/

— Gilles 'SO- deja de ser malvado'
fuente

bueno, como este es un paquete destinado a la redistribución, tal enlace simbólico no está realmente bajo mi control. Pensé que los binarios de Linux serían más portátiles ... supongo que no.

— rubenvb