Raspberry Piでクロスコンパイルされたプログラムを実行すると、「そのようなファイルやディレクトリはありません」

最近Raspberry Piを購入しました。私はすでにそれを構成しており、自分のデスクトップ（amd64）にarm用のクロスコンパイラーをインストールしています。単純な「hello world」プログラムをコンパイルしてから、それをデスクトップからPiにでコピーしましたscp ./hello david@192.168.1.33:~/hello。私のPiにログインした後、実行するls -l helloと通常の応答が返されます。

-rwxr-xr-x 1 david david 6774 Nov 16 18:08 hello

しかし、それを実行しようとすると、次のようになります。

david@raspberry-pi:~$ ./hello
-bash: ./hello: No such file or directory

david@raspberry-pi:~$ file hello
hello: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=0x6a926b4968b3e1a2118eeb6e656db3d21c73cf10, not stripped
david@raspberry-pi:~$ ldd hello 
    not a dynamic executable

ldd動的実行可能ファイルではない場合は、間違ったターゲット用にコンパイルされています。

言うまでもなくfile、32ビットARM実行可能ファイルはクロスコンパイルされています。ただし、「ARM」アーキテクチャが複数あるため、ツールチェーンが正しく構成されていない可能性があります。

crosstool-NGを使用し.configている場合は、の値を確認してくださいCT_ARCH_ARCH。ラズベリーpiの場合、「armv6j」¹である必要があります。少なくとも、それが私にとっては有効です。他にも詳細がありますが、私は考えてそれが十分でなければなりません。残念ながら、それが間違っている場合は、再構築する必要があります。

IMOがクロスコンパイラツールチェーンを機能させるのは面倒でイライラする場合がありますが、ホストは重要な要素ではない（そうすべきではありません）と仮定すると、この場合は実行できます。Crosstool-ngはTLIコンフィギュレーターを使用するため、複数のビルドを試す必要が生じた場合は、毎回選択内容を書き留めて、何が機能したかを把握してください。

¹ armv7ははるかに一般的なアーチ（多くの電話など）であるため、一般的なARMクロスコンパイラと思われるものを使用している場合、それがおそらく問題です。たとえば、piのプロセッサはARM11ですが、（そのページのとおり）ARM11ファミリのプロセッサはARMv6アーキテクチャを使用しています。つまり、ARM11はARMv6の実装です。

最初に--staticオプションを指定してプログラムをコンパイルし、次にテストします。それが静的として機能する場合、ラズベリーパイ上で

cat "programname" | grep "lib*"
/lib/ld-linux.so.3
libc6.so 

次に、すべてのライブラリが存在するかどうかを確認します

私はこのように解決しました。私は仕事をして/lib/ld-linux-armhf-so.3いません/lib/ld-linux.so.3 が、ln -s間にはありません

問題を特定する方法は？

file cross_compiled_executable

次のようなものが含まれています：

interpreter /lib/ld-uClibc.so.0

そして問題は、そのファイルがターゲットに存在しないことです。

問題を解決するには？

適切なコンパイラーを使用します。

• ディスクイメージを作成した人は、クロスコンパイラを提供するか、たとえばcrosstool-ngを使用して、そのビルド方法を正確に指示する必要があります。RPIの入手方法はこちらで尋ねられました。
• ビルドルートなどを使用して、独自のイメージとクロスコンパイラをコンパイルします。ここで、一般的なQEMU例。Buildroot はRPIをサポートしています。

• ターゲットでネイティブコンパイラを使用します。しかし、一般的にターゲットはホストよりもはるかに遅く、スペースが限られているため、これを実行することは望ましくありません。

  また、QEMUなどの機能エミュレーターを使用してビルドし、gem5や低速ボードなどの低速プラットフォームでのみプログラムを実行することもできます。

をハックアップするinterpreterだけでは十分でない可能性があります。特に、プログラムとターゲットlibc、またはプログラムとカーネルインターフェイス（syscalls /procなど）間のバイナリ互換性を確認する必要があります（-staticターゲットカーネルが古すぎる可能性があり、必要なインターフェースが含まれていません）。唯一の堅牢なソリューションは、正しいツールチェーンを使用することです。

ターゲットシステム上のライブラリは、実行可能ファイルがコンパイルされたホストシステムとは異なります。

makeを使用している場合は、CFLAGSとLDGLAGSに--staticオプションを含める必要があります。ストレートgccを使用している場合は、実行可能ファイルを移植できるように--staticオプションを使用します。