バイナリファイルの実行：ファイルが見つかりません

9

似たような質問があることは知っていますが、解決策も正確なケースも見つかりません。バイナリは、GCC 4.7を使用してArch Linuxで構築されました。パッケージはビルドシステムで正常に動作します。以下のコマンドが実行されました：

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

問題のファイルはここにあります。これは、Linux 64ビットからWindows 64ビットへのクロスコンパイラーです。解凍すると~/、~/mingw64必要なものがすべて含まれる単一のディレクトリが作成されます。

私が実行しようとすると、~/mingw64/x86_64-w64-mingw32/bin/asこれは私が得るものです：

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

実行するとfile ~/mingw64/x86_64-w64-mingw32/bin/as、次のようになります。

/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

実行するとldd ~/mingw64/x86_64-w64-mingw32/bin/as、次のようになります。

    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)

私は本当に途方に暮れています。どんな助けでも大歓迎です。

編集：もう少し詳細：ビルドシステムはArch Linux（現在はglibc 2.16）です。の出力ls -lは次のとおりです。

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

の出力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

ldd -vUbuntu 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は、Fedora 17（glibc 2.15）およびUbuntu 12.04（eglibc 2.15）です。zlibとglibcの両方のバージョン要件が満たされています。

ubuntu  files  compiling  binary  patchelf 
— rubenvb
ソース
それは単なるタイプミスですか、それとも実際に「〜/ mingw64 / x86_64-w64-mingw32 / as」を実行しようとしていますか？「bin」フォルダーがありません
— Tripledes 2012
@tripledesタイプ、修正済み。
— rubenvb
奇妙なことに、ダウンロードしようとしたところ、私の〜の下でuntarすると、期待どおりの結果が得られました。ls -l〜/ mingw64 / x86_64-w64-mingw32 / bin / asを提供できますか？
— Tripledes 2012
1
libcのバージョンが一致していない可能性がありますか？「objdump -p <path / to / as>」を実行して、「バージョン参照」セクションを確認してください。かなり新しいと考えられるGLIBC_2.14に依存しているように見えます。システムのバージョンは何ですか？"readelf -a <path / to / as> | less"およびGLIBCのgrepを実行すると、2.14のmemcpyが使用されていることがわかります。ライブラリの呼び出しによってバージョンが大きく異なる理由がわかりません。
— svenx

回答:

8

ldd -v as私のシステムで実行すると、次のようになります。

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

ええ、そうです、これらのバイナリがGLIBC_2.14シンボルを探しているように見えます。おそらくあなたのシステムにはありません。svenxが指摘したように、memcpy@@GLIBC_2.14シンボルを検索しているようです。memcpy新しいバージョンが提供された理由の詳細については、このバグレポートで説明しています。

glibcターゲットシステムにの新しいバージョンをインストールすると修正されます。古いバージョンので動作するようにバイナリを再構築したい場合はglibc、ここにリストされているようなトリックを試すことができます。またmemcpy、必要なシンボルの特定のバージョンを提供するだけのシムを使用して問題を解決することもできますが、これは少しハッキーです。

更新を読んだ後：そうです、それはあなたの問題ではありませんでした。しかし、私はそれを見つけたと思います：あなたのバイナリはインタプリタを要求していますが/lib/ld-linux-x86-64.so.2、これはUbuntu 12.04システムには存在しません：

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

一方でldd、それを見つけるために知っていた/lib64代わりに、私はカーネルが、それはバイナリを実行しようとしたときにことを知らないと、ファイルの要求されたインタプリタを見つけることができないと仮定します。インタプリタを介して手動で実行することもできます：

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

私はこれが正しく機能していることを100％確信していません-私のシステムでは、gccこのように実行するとセグメンテーション違反が発生します。しかし、それは少なくとも別の問題です。

— ジム・パリ
ソース
1
もしそうなら、それは良かったでしょう。更新を参照:(
— rubenvb
回答を更新しました。
— ジム・パリ
わあ、わかった。この種の吸う。この問題を回避する適切な方法を考えることはできません（そしてArchを構築し続けます）。素晴らしいアイデアはありますか？
— rubenvb
1
あんまり。Archはバカなだけです-Filesystem Heirarchy Standardは、ライブラリは/lib64amd64にあるべきだと明言しており、明らかにArchは手動でgccソースにパッチを適用してこれを変更し、それにより他のすべてのLinuxディストリビューションとの非互換性を保証しています。彼らの奇妙な推論については、このバグレポートのコメントを参照してください。私にとって、これはArch Linuxに近づかないようにする明確な警告サインになるでしょう。
— ジム・パリ
1
つまり、patchelfを使用してインタープリターの場所を変更できます。この問題に遭遇した別の人については、この投稿を参照してくださいpatchelf。
— ジム・パリ
0

あなたの問題は、64ビットシステムで32ビットバイナリを実行しているときに「見つかりませんでした」というメッセージが表示されることの変形です。ダイナミックローダーが存在しない実行ファイルがあります。

あなたの場合、ダイナミックローダーは/lib/ld-linux-x86-64.so.2存在しますが、別の場所にあり/lib64/ld-linux-x86-64.so.2ます。プログラムを機能させる最も簡単な方法は、シンボリックリンクを作成することです。

ln -s ../lib64/ld-linux-x86-64.so.2 /lib/
— ジル 'SO-悪をやめる'
ソース
まあ、これは再配布用のパッケージなので、そのようなシンボリックリンクは実際には私の管理下にありません。Linuxバイナリの方が移植性が高いと思いました...そうではありません。
— rubenvb 2012
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.