2012-11-02 8 views
5

私は過去3日間、仮想Ubuntu(12.04)を使用してTechNexion Blizzardボード(Unstromの不明なバージョンを実行中)用にMono 2.11.4をクロスコンパイルしようとしていました。 Win7 32ビットマシンとCodeSourcery Sourcery G ++ ARMツールチェーンですが、ほとんどまたはまったく成功しません。 私はWeb上のすべてのチュートリアルに従ってきましたが、うまくいきません。MonoをARM用にクロスコンパイルできない

CodeSourcery Sourcery G ++ツールチェーンとScratchbox2(最新のgitソースからコンパイルされたもの)がインストールされ、動作しています。 Scratchbox2はしばらく正しいディレクトリ内(〜/ CodeSourcery社/ Sourcery_G ++ _ライト/アームなし - のlinux-gnueabi/libcの)

sb2-init armv7 /home/dev/CodeSourcery/Sourcery_G++_Lite/bin/arm-none-linux-gnueabi-gcc 

を使用してそれを設定しました。

単純な「Hello world」(cpp)をコンパイルし、コンパイルしてボード上で実行することができます。 Ubuntuのでは:

file hello 
hello: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, not stripped 

私はモノ2.11.4のソースをダウンロードしてinstructionsの1に従いました。最初の部分(ネイティブマシン上)は正常に動作し、エラーは発生しません。しかし、私が2番目の部分(ARMのコンパイル)を実行すると、./configureは期待通りに機能しますが、で失敗します。 "../lib/mini[some_file]はアーム出力"と互換性がありません。 A これらのファイルのファイルは、実際にはIntel 80386の実行可能ファイルだと言いますが、理由はわかりません。

したがって、次のステップではを実行してをクリーンアップして手順を繰り返しますが、それでも同じ結果が得られました。

私はその後は./configureにしようとした代わりSB2内全部を行い、最初で仕事をするように見えました。しかし、その後いくつかのエラーは、ビルドが壊れたポップアップ:

./.libs/libmini.a(libmini_la-mini-arm.o): In function `mono_arch_init': 
/home/dev/source/host-mono/mono-2.11.4/mono/mini/mini-arm.c:689: undefined reference to `debugger_agent_single_step_from_context' 
/home/dev/source/host-mono/mono-2.11.4/mono/mini/mini-arm.c:689: undefined reference to `debugger_agent_breakpoint_from_context' 
/home/dev/CodeSourcery/Sourcery_G++_Lite/bin/arm-none-linux-gnueabi-ld: .libs/libmono-2.0.so.1.0.0: hidden symbol `debugger_agent_single_step_from_context' isn't defined 
/home/dev/CodeSourcery/Sourcery_G++_Lite/bin/arm-none-linux-gnueabi-ld: final link failed: Nonrepresentable section on output 

私が間違ってやって上の任意のアイデア、または私が見逃している可能性がありますチュートリアル上の任意のヒント?

//アンダース

+0

mono 2.11.4でmono 3.0ではないのはなぜですか? 11は奇数なので「不安定」を意味します – knocte

+0

確かに、私は2.10.9で試してみることができますが、どちらもコンパイルするとは思いません。しかし、私は試みます。 3.0はまだベータ版ですので、これは現在オプションではありません。 – user1143242

+0

モノ3.0がコンパイルされ、古いバージョンではなく、むしろ何もないのではないでしょうか? ;)btwどこで3.0を読んだのですか? – knocte

答えて

1

それは新しいターミナルを開いて、マネージコードをビルドする他の側にネイティブコード

[sbox-ARMEL: ~] > mkdir cross 
[sbox-ARMEL: ~] > cd cross 
[sbox-ARMEL: ~] > tar xzf ../mono-x.xx.tar.gz 

[sbox-ARMEL: ~] > cd arm-mono-x.xx 
[sbox-ARMEL: ~] > ./configure --disable-mcs-build 
[sbox-ARMEL: ~] > make 
[sbox-ARMEL: ~] > make install DESTDIR=`pwd`/tmptree 

をコンパイルするためScratchBoxを使用することをお勧めします。

$ mkdir host-mono 
$ cd host-mono 
$ tar xzf ../mono-1.xx.tar.gz 

$ cd mono-1.xx 
$ ./configure 
$ make 
$ make install DESTDIR=`pwd`/tmptree 
+2

したがって、Scratchbox2よりもScratchboxの方が使いやすいですか? 私はある種の深刻なグーグル・グーグルをしているとき、それは逆の(それはSb2が良い)という気持ちを持っています。 – user1143242

0

あなたがクロスコンパイルする場合に対してコンパイルしたり、図書館に対するバイナリ互換性の問題によって引き起こされ、実行時に奇妙なと直感的にクラッシュして自分自身を見つけることができたヘッダとライブラリは非常に注意する必要があります。これを言うと、LinuxのARMディストリビューションは、バイナリ互換性で非常に安全です(通常はパフォーマンスを犠牲にします)。

開発ホストのヘッダーとライブラリに対してビルドしている可能性があります。つまり、アーキテクチャの不一致です。

あらかじめ作成されたopkgイメージが機能することがわかります。 Angstromはpre-built packagesを提供します。これは、Angstromパッケージリポジトリからのネットワークインストールと同じくらい簡単かもしれません。

ソースからビルドする必要がある場合は、問題への簡単な解決策の1つは、Angstromのビルド環境を取得してモノを構築することです。これについては、the Angtrom online image builderからあらかじめ作成された画像(および開発用画像)を取得するのが最も簡単な方法です。運があればあなたのボードに1つの存在があります。

+0

残念ながら、ボードはNarcissusのページには載っていませんが、もっと深く掘り下げて "compatibles"があるかどうかを調べる必要があります。 – user1143242

+0

私はBeagleboardをテストする際にビルダーを何度も使用しましたが、Monoを組み込むときにビルドを完了することは決してありませんでした。なぜか分かりません。ちょうどうまくいきません... 作業中のScratchbox2のように見えるものをコンパイルするとき、私は安全にプレイしていると思っていました。私が言ったように、私は簡単なプログラム(とSqlite3)でもコンパイルできますが、Monoは失敗します。 – user1143242

+0

私はすでに(** opkg **を使ってインストールされた)既製のMonoを使用していますが、残念ながらバージョン2.6.3です。 .NET 4.0のコードを実行するには2.10.xが必要です。 2.10.8はあらかじめ構築されていますが、Angstromの新しいバージョンのためだけに使用していますので、代わりにAngstromをアップグレードすることに集中すべきでしょうか? – user1143242

関連する問題