executando arquivo binário: arquivo não encontrado

Question

Eu sei que existem perguntas semelhantes por aí, mas não encontrei uma solução nem neste caso exato. O binário foi construído no Arch Linux usando seu GCC 4.7. O pacote funciona bem no sistema de compilação. Os comandos abaixo foram executados em:

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

O arquivo em questão está localizado aqui . É um compilador cruzado Linux de 64 bits para o Windows de 64 bits. Descompactá-lo para ~/ fornece um único diretório ~/mingw64 que contém tudo o que é necessário.

Quando tento executar ~/mingw64/x86_64-w64-mingw32/bin/as , é o que recebo:

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

A execução de file ~/mingw64/x86_64-w64-mingw32/bin/as me dá:

/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

A execução de ldd ~/mingw64/x86_64-w64-mingw32/bin/as me dá:

    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)

Estou verdadeiramente perdido. Qualquer ajuda é muito apreciada.

EDITAR : mais alguns detalhes: O sistema de compilação é o Arch Linux (atualmente glibc 2.16). A saída de ls -l é:

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

A saída de objdump -p é:

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

A saída de ldd -v no Ubuntu 12.04 é:

    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

Os outros sistemas operacionais testados são o Fedora 17 (glibc 2.15) e o Ubuntu 12.04 (eglibc 2.15). Os requisitos da versão zlib e glibc são atendidos.

    

Answer 1

Se eu executar ldd -v as no meu sistema, obtenho:

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

Então, sim, parece que esses binários estão procurando por um símbolo GLIBC_2.14 , que você presumivelmente está faltando no seu sistema. Como o svenx apontou, parece que ele está procurando pelo símbolo memcpy@@GLIBC_2.14 . Mais informações sobre por que o memcpy recebeu uma nova versão é descrito neste relatório de bug .

A instalação de uma nova versão do glibc em seu sistema de destino deve corrigir isso. Se você quiser tentar reconstruir o binário para continuar trabalhando na versão antiga de glibc , você pode tentar truques como o listado aqui . Você também pode se dar bem com um shim que apenas forneça a versão específica do símbolo memcpy que você precisa, mas isso pode ser um pouco hacky.

Depois de ler sua atualização : você está certo, não foi problema seu. Mas acho que descobri: seu binário está solicitando o intérprete /lib/ld-linux-x86-64.so.2 , que não existe nos sistemas Ubuntu 12.04:

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

Enquanto ldd sabia encontrá-lo em /lib64 , eu suponho que o kernel não sabe disso quando tenta executar o binário e não consegue encontrar o interpretador requisitado pelo arquivo. Você poderia tentar apenas executá-lo através do interpretador 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'.

Eu não tenho 100% de certeza de que isso está funcionando corretamente - no meu sistema, executar gcc dessa maneira gera uma falha de segmentação. Mas isso é pelo menos um problema diferente.

    

Answer 2

Seu problema é uma variante de : você tem um executável que menciona um carregador dinâmico que não está lá .

No seu caso, o carregador dinâmico /lib/ld-linux-x86-64.so.2 existe, mas em um local diferente /lib64/ld-linux-x86-64.so.2 . A maneira mais simples de fazer seus programas funcionarem seria criar um link simbólico:

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