[Mono-dev] Re: Cross Compiling Mono For ARM

Buchegger Hanspeter hanspeter.buchegger at leister.com
Thu Dec 21 12:13:37 EST 2006


I’m trying to use mono for an embedded system with a Cirrus ARM9 processor, running Linux 2.4.

Here is a short description of my experience. Maybe it helps other users and/or maybe there is some advice for me to get it fixed.

The packages used are:
- mono-1.2.1
- glib-2.12.4
- cross-compiler gcc-3.3.2 (compiler has a prefix of 'arm-unknown-linux-gnu')

First, I had to cross- compile the Glib (from the GTK- project), mono depends on it.
I’ve done this on a cygwin- installation under windows (no, I'm not a Windows-fan and would prefer to have a Linux- box to do this :-)), so maybe under Linux it might be different. I used the following configure:

configure –host=arm-unknown-linux-gnu –cache-file=arm_cross.cache –prefix=/usr/local

The cache- file is needed due to the fact that configure can’t compile/run test-code while cross- compiling. So we have to set all variables which afford test-runs manually. I’ve found the symbols on the GTK- project- website.
My cache- file (named arm_cross.cache, see above):


Ok, now I started ‘make’, then I ran into problems with ‘global_symbol_pipe’, configure stopped somewhere in libtool with a syntax- error. The problem is based on the failure of configure to set the variable ‘global_symbol_pipe’. To avoid further stops I put the following line directly into ‘libtool’:

global_symbol_pipe="sed -n -e 's/^.*[   ]\\([ABCDGIRSTW][ABCDGIRSTW]*\\)[       ][      ]*\\(\\)\\([_A-Za-z][_A-Za-z0-9]*\\)\$/\\1\\2\\3 \\3/p'"

I got this from another package, I don’t understand exactly, what it does (I have some personal troubles with regExp’s in general :-) ), but it worked. My first attempt to ignore the 'global_symbol_pipe' by simply putting ‘cat’ into it, wasn’t working. The above regExp is used to filter output from the nm- tool. If it isn’t filtered correctly, the linker will stop with something like ‘syntax error in VERSION file’. 
Attention: put this in the ‘libtool’- file AFTER you’ve successfully run 'configure'. ‘libtool’ is generated by configure, if you restart configure, a new ‘libtool’- file is generated and therefore your changes are lost. I don’t have the time to investigate the problem further; advice to fix it is desired.

‘make’ then terminated without problems. I ran ‘make install’ to put the libs into the right place (in my case /usr/local/lib ...). But be careful: if you are working on a Linux- box, which might have the glib- /gtk- libraries installed to run GTK- based software (example: gimp), make sure you do not overwrite the native libs used to run it. The generated libs are native ARM- code and therefore do not run on a Linux- X86 box.

Next step: to cross-compile mono itself, but I got endless troubles, which are, in my opinion, related to the cygwin- environment. I’m doing another attempt on my Linux- box at home (Kernel 2.6.x, cross-gcc4.0.x) and it seems to work much better, glib compiled and installed with the above mentioned cache-file without any troubles. Still mono doesn’t compile without errors. If there is any interest in this, I can post my experiences.

So, now I have glib, but still no mono. To get around the problem, I got the Mono- package for the Nokia 770- device (from the mono- project- website). This is a debian- package, so I unpacked it (dpkg-deb  ) and installed the mono- binary and the mscorelib.dll manually. You also need librt-so.1 (librt-2.3.2.so) from the debian- ARM- package libc6 (package- names see below).

Nokia- package           : mono-nokia_1.1.13-1_arm.deb
Debian-ARM libc6- package: libc6_2.3.2.ds1-22sarge4_arm.deb (to extract librt-2.3.2.so)

And guess what? It works.... I was able to run some simple console- programs with mono on my EP93xx- based ARM. Windows-Forms will not work with my setup, but my platform doesn’t have any video- device and is used as an embedded controller, so I’m not interested in GUI’s. Maybe my complicated setup will work for my purposes; I have to do some tests to verify. 


More information about the Mono-devel-list mailing list