Nie można skompilować krzyżowo Mono dla ARM

Question

Przez ostatnie trzy dni próbowałem skompilować Mono 2.11.4 na pokładzie TechZexion Blizzard (z uruchomioną nieznaną wersją Angstroma) używając wirtualnego Ubuntu (12.04) na moim 32-bitowa maszyna Win7 i CodeSourcery Sourcery G ++ ARM toolchain, ale z małym/żadnym sukcesem. Podążałem za każdym tutorialem w Internecie, ale to po prostu nie działa.

CodeSourcery Sourcery G ++ toolchain i Scratchbox2 (skompilowane z najnowszych źródeł Git) są zainstalowane i działają. Scratchbox2 go ustawić za pomocą

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

podczas gdy w odpowiednim katalogu (~/CodeSourcery/Sourcery_G ++ _ Lite/arm-none-linux-gnueabi/libc).

Potrafię skompilować prosty "Hello world" (cpp), skompilować i uruchomić go na tablicy. W 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 

I ściągnięty źródło dla Mono 2.11.4 a następnie jedną z instructions. Pierwsza część (na maszynie natywnej) działa dobrze, bez błędów. Jednak po uruchomieniu drugiej części (kompilacja dla ARM) ./configure działa zgodnie z oczekiwaniami, ale następnie kończy się niepowodzeniem z "../lib/mini[some_file] jest niekompatybilny z wyjściowym ramieniem". Plik plik na tych plikach mówi, że rzeczywiście są to pliki wykonywalne Intel 80386, ale nie wiem dlaczego.

Kolejnym krokiem było wykonanie czyszczenia make clean i powtórzenie kroków, ale nadal zapewniało ten sam wynik.

Potem próbował ./configure i zrobić cała sprawa wewnątrz zamiast SB2 i wydawało się do pracy w pierwszej kolejności. Ale niektóre błędy pojawiło się kompilacja złamał:

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

Wszelkie pomysły na to, co robię źle, albo jakieś wskazówki dotyczące samouczków mógłbym przegapić?

// Anders

Answer 1

Lepiej używać ScratchBox do kompilacji kodu natywnego

[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 

z drugiej strony otwiera nowy terminal i zbudować kodu zarządzanego.

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

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

Answer 2

Musisz być bardzo ostrożny, który nagłówki i biblioteki skompilować przeciwko kiedy cross-kompilacji lub mogą znaleźć się dziwaczne i przeciwbieżne intuicyjny wypadków w czasie wykonywania spowodowanych przez niezgodności binarnych przeciwko bibliotek. Mówiąc to, dystrybucje ARM systemu Linux grają bardzo bezpiecznie z kompatybilnością binarną - zwykle kosztem wydajności.

Jest całkiem możliwe, że budujesz na swoich nagłówkach i bibliotekach deweloperskich - stąd niedopasowanie architektury.

Możesz po prostu stwierdzić, że gotowe obrazy OPkg działają. Angstrom zapewnia dla ciebie pre-built packages. Może to być tak proste, jak instalacja sieciowa z repozytorium pakietów Angstrom.

Jeśli okaże się, że musisz zbudować ze źródła, jednym prostym rozwiązaniem problemu będzie uzyskanie środowiska kompilacji dla Angstrom i użycie go do zbudowania mono. Najłatwiejszym sposobem na uzyskanie tego jest uzyskanie gotowego obrazu (i obrazu rozwojowego) z the Angtrom online image builder. Przy odrobinie szczęścia istnieje na twojej planszy.