Can Mono 2.4 Ahead-Of-Time (AOT) compile on FreeBSD x86 (or x64)?

Question

I use a shared web server (NearlyFreeSpeech.net, highly recommended!) running FreeBSD 7.2 and would love to write CGI scripts for it using C# but they have not installed Mono on there yet. If I use my own FreeBSD 7.2 box and compile my C# programs there, can I AOT compile my code and deploy the binaries on the Mono-less server?

I know multiple iPhone games are selling on the App Store and all of those are AOT compiled (to ARM). And the above referenced page says x86 and x64 are supported, but on my x86 Mac OS X Leopard Mono install I tried

sudo mono --aot /Library/Frameworks/Mono.framework/Versions/2.4.2.1/lib/mono/2.0/mscorlib.dll

and

sudo mono --full-aot /Library/Frameworks/Mono.framework/Versions/2.4.2.1/lib/mono/2.0/mscorlib.dll

and got the errors:

AOT compilation is not supported on this platform.

and

Failed to load AOT module '/Library/Frameworks/Mono.framework/Versions/2.4.2.1/lib/mono/2.0/mscorlib.dll.dylib' in aot-only mode.

respectively. I just don't want to put a lot of work into getting FreeBSD 7.2 + Mono 2.4.2.1 working and find out the same thing: AOT compilation is not supported, which is the only reason for caring about FreeBSD + Mono for me...

Answer 1

AOT only removes the need for (most) JIT-compiling. You still need the VM for all the other services it provides - garbage collection, metadata, IO, security, dynamic compilation, etc.

The advantage of AOT in a desktop environment is to reduce startup time, allow more expensive compiler optimizations to be used, and to allow code sharing between apps.

The iPhone is a special case, since it disallows both dynamic libraries and JITing. So the CLI code is AOT-compiled into static libraries which are then linked together with a slimmed down Mono runtime, producing a single binary. However, disabling the JIT adds some limitations. For example, certain uses of generics are impossible (the AOT compiler cannot always statically determine which reified generic types it needs to compile), and dynamic code generation (needed by languages like IronPython) is impossible.

Your best bet would be to build a Parallel Mono Environment - either build it directly on the remote machine, or build it locally, install into some temp prefix, tar that and copy it over.