5

For the last three days I've been trying to cross-compile Mono 2.11.4 for the TechNexion Blizzard board (running an unknown version of Angstrom) using a virtual Ubuntu (12.04) on my Win7 32 bit machine and CodeSourcery Sourcery G++ ARM toolchain, but with little/no success. I've followed every tutorial on the web but it just doesn't work.

CodeSourcery Sourcery G++ toolchain and Scratchbox2 (compiled from the latest git sources) are installed and working. Scratchbox2 set it up using

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

while in the correct directory (~/CodeSourcery/Sourcery_G++_Lite/arm-none-linux-gnueabi/libc).

I can compile a simple 'Hello world' (cpp), compile and run it on the board. In 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 the downloaded the source for Mono 2.11.4 and followed one of the instructions. The first part (on the native machine) works well, no errors. However, when I run the second part (compiling for ARM) ./configure works as expected but then make fails with "../lib/mini[some_file] is incompatible with arm output". A file on these files says that they are indeed Intel 80386 executables, but I don't know why.

So the next step was to run a make clean and repeat the steps, but it still produced the same result.

I then tried to ./configure and make the whole thing inside sb2 instead and it seemed to work at first. But then some errors popped up the build broke:

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

Any ideas on what I'm doing wrong, or any tips on tutorials I might have missed?

//Anders

Community
  • 1
  • 1
user1143242
  • 51
  • 1
  • 3
  • why mono 2.11.4 and not mono 3.0? 11 is an odd number so it means "unstable" – knocte Nov 03 '12 at 15:38
  • Sure, I can try with 2.10.9 but I don't think it will compile either. But, I will try. 3.0 is still in beta so that's not an option now. – user1143242 Nov 04 '12 at 19:39
  • if mono 3.0 compiles and the older versions don't, rather have that instead of nothing, no? ;) btw where did you read 3.0 is flagged as a beta? – knocte Nov 05 '12 at 00:53
  • 1
    On the [Mono download page](http://www.go-mono.com/mono-downloads/download.html) it reads **Beta Version: 3.0** but perhaps they only mean the prebuilt OSX binaries. I will check the source instead. – user1143242 Nov 05 '12 at 07:46

2 Answers2

0

It's better to use ScratchBox for compiling native code

[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

on the other side open a new terminal and build managed code.

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

$ cd mono-1.xx
$ ./configure
$ make
$ make install DESTDIR=`pwd`/tmptree
Omid Mafakher
  • 1,389
  • 1
  • 16
  • 40
  • 2
    So Scratchbox is better to use than Scratchbox2? I kind of got the feeling that it was the other way around (that Sb2 is better) when doing some serious googling. – user1143242 Nov 04 '12 at 19:43
0

You need to be very careful which headers and libraries you compile against when cross-compiling or you can find yourself with bizarre and counter-intuitive crashes at runtime caused by binary incompatibilities against libraries. In saying this, Linux ARM distros play very safe with binary compatibility - usually at the expense of performance.

It's quite possible that you're building against your development hosts headers and libraries - hence the architecture mismatch.

You might just find that pre-built opkg images just work. Angstrom provides pre-built packages for you. It might be as simple as network-installing from Angstrom package repository.

If you find you do need to build from source, one simple solution to your problem would be to get the build environment for Angstrom and use it to build mono. The easiest way of going about this is to get a pre-built image (and development image) from the Angtrom online image builder. With any luck one exists for your board.

marko
  • 9,029
  • 4
  • 30
  • 46
  • Unfortunately the board isn't listed on the Narcissus page, but I will have to dig down deeper and see if there are any "compatibles". – user1143242 Nov 05 '12 at 07:49
  • I've used the builder lots of times when testing the Beagleboard but I have never managed to complete a build when including Mono. Don't really know why, it just doesn't work... I thought I was playing it safe when compiling inside of what looks to be a working Scratchbox2. As I said: I can compile simple programs (and even Sqlite3) but Mono fails. – user1143242 Nov 05 '12 at 07:59
  • I'm already using the pre-built Mono (installed using **opkg**) but unfortunately it is version 2.6.3. I need 2.10.x to run my .NET 4.0 code. 2.10.8 exists as a pre-built but only for a newer version of Angstrom than I'm using so perhaps I should focus on upgrading Angstrom instead? – user1143242 Nov 05 '12 at 07:59
  • I've had mono running on an OMAP3 and OMAP4 system in the past. It's a huge addition to the system image however! It's only really the kernel and bootloader that is board specific, so if you already have one (which it appears you have) you just need an Angstom image built for the correct ARM architecture version. – marko Nov 05 '12 at 08:41