I've been chasing it for about a week now, but have finally isolated the cause of the ARM problems I mentioned.

I've been using the default Ubuntu Maverick environment on the Efika MX, due to the lack of TO3-capable Debian image. This has three remotely relevant versions of GCC available:

• 4.3.5-3ubuntu1
  
• 4.4.4-14ubuntu5
  
• 4.5.1-7ubuntu2
  

After a significant number of fights with CFLAGS to try and build a more cut-down Mono, I started trying the multiple GCC releases, and found that whilst the gcc-4.3 package produced a fully functional Mono binary, the other two produced a Mono binary which would hang forever (or throw SIGILL or SIGSEGV) when faced with a NullReferenceException in executed code, likely due to Thumb instructions in the wrong place. Vincent Sanders and Geoff Norton helped greatly with debugging the Mono runtime to isolate where the issues were happening.

On a hunch, I tried the same set of compiler packages in Debian:

• 4.3.5-4
  
• 4.4.5-5
  
• 4.5.1-9
  

Now, the interesting thing is, in Debian, all three compilers produce a working Mono runtime. The difference? As far as I can determine, Linaro patches to GCC. gcc-4.3 is the only Ubuntu compiler without Linaro patches - and also the only functional Ubuntu compiler.

There's now a bug opened to track this issue: https://bugs.launchpad.net/gcc-linaro/+bug/667225

Am testing Mono 2.8 ARM support. Seems to work great with a binary built on a Debian ARMv5 machine, but not on the Efika MX. Am following up with upstream - hopefully they can reproduce the issue on their Tegra

Time for some specifics on what was required to make Moonlight work on ARM.

There were two issues, which I'll discuss separately.

Firstly, there's Firefox's plugin ABI. In order to ensure that you don't try to install plugins intended only for one architecture onto a different architecture, Firefox assigns a browser an ABI, such as Linux_x86_64-gcc3 or Linux_ia64-gcc2. This is detailed here: https://developer.mozilla.org/en/XPCOM_ABI

Now, the way we build Moonlight packages doesn't technically need this info (as we're not generating an XPI file), but Moonlight's build system makes use of firefox-xpi.m4 for some build checks. And, infuriatingly, there is no XPCOM ABI defined for Linux ARM. So... cheap workaround: edit firefox-xpi.m4 to set the null value, Linux_UnknownABI, on Linux/ARM

Next, there was some untested API skew upstream. Some portions of the Moonlight plugin code are duplicated - one version for platforms with official Microsoft-provided binary codecs (i386 and AMD64), and one version for other platforms. At some point in the past, the method signature in one of these files was changed in the codec version of a file - but not the nocodec version. As a result, the nocodec version no longer compiled. I told the Moonlight upstream about the problem, and they committed a simple fix to the API in the nocodec version of the file, fixing compilation on ARM, PowerPC, Itanium, etc.

Here's a picture:

Only six days before shipping, Ubuntu Maverick gained its first direct result of this project: with relevant and recent hardware to develop on, two bugs in the Moonlight plugin (for playing Silverlight content) preventing compilation on ARM were fixed. As a bonus, one of these also affected PowerPC compilation. apt:moonlight-plugin-mozilla and apt:moonlight-plugin-chromium are fully functional, on moon 2.3-0ubuntu4.

Debian development is on hold, awaiting a new armhf SD image with support for the TO3 hardware (the current image on my SD card doesn't boot)