組み込み(カスタム)ARMベースのLinuxシステム用にいくつかのCコードをコンパイルしようとしています。私は、必要なもののように見えるので、arm-linux-gnueabi-gcc-4.4というクロスコンパイラを使ってUbuntu VMをセットアップしました。私はこのGCCと私のコードをコンパイルするとき今、それはこのようなバイナリを生成します。組み込みARMベースのLinuxシステム用のクロスコンパイル
$ file test1
test1: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked
(uses shared libs), for GNU/Linux 2.6.31,
BuildID[sha1]=0x51b8d560584735be87adbfb60008d33b11fe5f07, not stripped
私は組み込みLinux上で、このバイナリを実行しようとすると、私は
$ ./test1
-sh: ./test1: not found
権限を取得するのに十分です。私は何かがバイナリ形式で間違っていることを想像することができますので、私はリファレンスとして、いくつかの作業バイナリを見て:
$ file referenceBinary
referenceBinary: ELF 32-bit LSB executable, ARM, version 1, dynamically linked
(uses shared libs), stripped
私はいくつかの違いがあることがわかり、私は私が必要正確に何を導出するための知識を持っていません修正する方法と私はそれを修正する方法。誰かがどのような違いが重要かを説明することができますか
私が見てもう一つは、依存関係です:
$ ldd test1
libc.so.6 => not found (0x00000000)
/lib/ld-linux.so.3 => /lib/ld-linux.so.3 (0x00000000)
(それはバイナリを実行することはできませんが、興味深いことに、これは、ターゲットシステム上で動作します。)組み込みシステムでのみ利用可能libc.so.0
を持っています。私はリンクしたいlibcのバージョンをコンパイラに伝える必要があると思うが、理解している通り、gccはそれが付属しているバージョンとリンクしているだけで正しいのだろうか?それについて私は何ができますか?
編集:ここで私が使用したMakefileだ:
CC=/usr/bin/arm-linux-gnueabi-gcc-4.4
STRIP=/usr/bin/arm-linux-gnueabi-strip
CFLAGS=-I/usr/arm-linux-gnueabi/include
LDFLAGS=-nostdlib
LDLIBS=../libc.so.0
SRCS=test1.c
OBJS=$(subst .c,.o,$(SRCS))
all: test1
test1: $(OBJS)
$(CC) $(LDFLAGS) -o main $(OBJS) $(LDLIBS)
$(STRIP) main
depend: .depend
.depend: $(SRCS)
rm -f ./.depend
$(CC) $(CFLAGS) -MM $^>>./.depend;
clean:
rm -f $(OBJS)
include .depend
メモリが逼迫している場合は、はるかに小さい 'uClibc'が' glibc'を置き換えることができます。しかし、 'uClibc'を使うために* gcc *コンパイラが必要です。 * gcc *、* uClibc *(または* glibc *)とフレンドの作業ツールチェーンを取得し、Linuxカーネル、Busybox、その他のパッケージをソースからビルドする方法(BuildRootを使用する方法)は比較的簡単です。良いコンパイラ+ libcの組み合わせでは、あなたのアプリケーションを静的にリンクすることができ、ターゲットのライブラリとは独立したものにすることができます。 – sawdust