esecuzione del file binario: file non trovato

So che ci sono domande simili là fuori, ma non ho trovato una soluzione né questo caso esatto. Il binario è stato costruito su Arch Linux usando GCC 4.7. Il pacchetto funziona perfettamente sul sistema di compilazione. I comandi seguenti sono stati eseguiti su:

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

Il file in questione si trova qui . È un cross-compilatore da Linux da 64 bit a Windows a 64 bit. La non decompressione ~/fornisce una singola ~/mingw64directory che contiene tutto il necessario.

Quando provo a eseguire ~/mingw64/x86_64-w64-mingw32/bin/asquesto è quello che ottengo:

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

Correre file ~/mingw64/x86_64-w64-mingw32/bin/asmi 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

Correre ldd ~/mingw64/x86_64-w64-mingw32/bin/asmi 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)

Sono davvero in perdita. Ogni aiuto è molto apprezzato.

EDIT : Qualche dettaglio in più: il sistema di compilazione è Arch Linux (attualmente glibc 2.16). L'output di ls -lè:

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

L'output di 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

L'output di ldd -vsu 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

Gli altri SO testati sono Fedora 17 (glibc 2.15) e Ubuntu 12.04 (eglibc 2.15). Sono soddisfatti i requisiti di versione di zlib e glibc.

— rubenvb
fonte

è solo un refuso o stai davvero cercando di eseguire '~ / mingw64 / x86_64-w64-mingw32 / as' ... manca la cartella 'bin'.

— tripledes

tipo @tripledes e corretto.

— rubenvb,

strano, ho appena provato a scaricare, untar sotto il mio ~ e ottengo il risultato previsto. Potresti fornire un ls -l ~ / mingw64 / x86_64-w64-mingw32 / bin / as?

— tripledes

Potrebbe essere una mancata corrispondenza della versione di libc? Prova a eseguire "objdump -p <percorso / to / as>" e controlla la sezione "Riferimenti versione". Potrebbe sembrare che dipenda da GLIBC_2.14, che potrebbe essere considerato abbastanza nuovo. Qual è la tua versione di sistema? "readelf -a <path / to / as> | less" e grep per GLIBC, vedrai che sta usando memcpy da 2.14. Non so perché la versione varierebbe così tanto tra le diverse chiamate in libreria.

— svenx,

Risposte:

Se corro ldd -v assul mio sistema, ottengo:

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

Quindi sì, sembra che questi binari stiano cercando un GLIBC_2.14simbolo, che presumibilmente ti manca sul tuo sistema. Come ha sottolineato Svenx, sembra che stia cercando il memcpy@@GLIBC_2.14simbolo. Alcune ulteriori informazioni sul perché è memcpystata fornita una nuova versione sono descritte in questo rapporto sui bug .

L'installazione di una nuova versione di glibcsul sistema di destinazione dovrebbe risolverlo. Se vuoi provare a ricostruire il binario per funzionare ancora con la vecchia versione di glibc, potresti provare trucchi come quello elencato qui . Potresti anche cavartela con uno spessore che fornisce solo la versione specifica del memcpysimbolo di cui hai bisogno, ma che diventa un po 'confusa.

Dopo aver letto l'aggiornamento : hai ragione, non è stato un tuo problema. Ma penso di averlo trovato: il tuo binario richiede l'interprete /lib/ld-linux-x86-64.so.2, che non esiste sui sistemi Ubuntu 12.04:

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

Mentre invece lddsapevo di trovarlo /lib64, suppongo che il kernel non lo sappia quando tenta di eseguire il binario e non riesce a trovare l'interprete richiesto del file. Potresti provare a eseguirlo manualmente attraverso l'interprete:

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

Non sono sicuro al 100% che funzioni correttamente: sul mio sistema, l'esecuzione in gccquesto modo genera un errore di segmentazione. Ma questo è almeno un problema diverso.

— Jim Paris
fonte

Sarebbe stato carino, se fosse così. Vedi aggiornamento:(

— rubenvb,

Ho aggiornato la mia risposta.

— Jim Paris,

Wow, ok. Questo tipo di schifo. Non riesco a pensare a un modo decente per aggirare questo problema (e continuare a costruire su Arch). Hai qualche idea geniale?

— rubenvb,

Non proprio. Arch è semplicemente stupido: il Filesystem Heirarchy Standard dice chiaramente che le librerie dovrebbero essere /lib64su amd64, e apparentemente Arch corregge manualmente i loro sorgenti gcc per cambiarlo, garantendo così l' incompatibilità con ogni altra distribuzione Linux là fuori. Vedi i commenti di questo bug report per il loro ragionamento bizzarro. Per me, questo sarebbe un chiaro segnale di avvertimento per stare lontano da Arch Linux.

— Jim Paris,

Detto questo, puoi cambiare la posizione dell'interprete usando patchelf . Vedi questo post per un'altra persona che ha riscontrato questo problema, che ha affermato che ha patchelffunzionato per loro.

— Jim Paris,

Il tuo problema è una variante del messaggio Ottenere "Non trovato" quando esegui un file binario a 32 bit su un sistema a 64 bit : hai un eseguibile che menziona un caricatore dinamico che non c'è.

Nel tuo caso, il caricatore dinamico /lib/ld-linux-x86-64.so.2esiste ma in una posizione diversa /lib64/ld-linux-x86-64.so.2. Il modo più semplice per far funzionare i tuoi programmi sarebbe quello di creare un collegamento simbolico:

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

— Gilles 'SO- smetti di essere malvagio'
fonte

bene, dato che si tratta di un pacchetto pensato per la ridistribuzione, un tale collegamento simbolico non è realmente sotto il mio controllo. Pensavo che i binari di Linux sarebbero stati più portatili ... suppongo di no.

— rubenvb,