Compiling Mono 3.x from Source with LLVM Code Generation in Ubuntu LTS x64

December 3, 2013 3 Comments

The packages for Mono in Debian and Ubuntu are lagging far behind what is available from Xamarin for OS X, SUSE and OpenSUSE. The 2.10.x versions of Mono are .NET 2.0 runtime compatible and use Mono’s older Boem garbage collector — which tends to leak objects. The new generational “sgen” garbage collector is far superior All of the tutorials for building on Fedora/RHEL/CentOS and Debian/Ubuntu that I have seen build with the built-in code generation engine rather than LLVM. LLVM provides a significant speedup in the generated code of 20-30% but Mono can’t link against the version of LLVM that ships in Debian Wheezy or Ubuntu. You have to build a tweaked version from source — which is the tricky bit.

My goal was to build the same version of Mono that is shipped by Xamarin for OS X on Ubuntu 12.04 Precise Pangolin, including LLVM. That is mono 3.2.5 at the time of this writing.

Screen Shot 2013 12 01 at 10 58 51 AMPrerequisites

Mono is hosted on GitHub so we need git. It also requires GNU autotools, make and g++ to drive the build. 

sudo apt-get install libtool autoconf g++ gettext make git

We’re building something that isn’t managed by the system package manager, so according to the UNIX Filesystem Hierarchy Standard, the build product should go into the /opt file system. I’m going to use /opt/local and so before going any further let’s add that to the $PATH by editing /etc/environment with vi or your editor of choice:

PATH=“/opt/local/sbin:/opt/local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games”

Also, we need to change the current environment:

export PATH=/opt/local/sbin:/opt/local/bin:$PATH

Libgdiplus

The first component of Mono that we need to build from source is libgdiplus. Libgdiplus is an open source implementation of the Windows GDI+ API for graphics and text rendering. Libgdiplus has a number of prerequisites because it basically just maps GDI+ function calls onto equivalent Linux libraries:

sudo apt-get install pkg-config libglib2.0-dev libpng12-dev libx11-dev libfreetype6-dev libfontconfig1-dev libtiff-dev libjpeg8-dev libgif-dev libexif-dev

mkdir ~/src; mdkr ~/src/mono; cd ~/src/mono

git clone https://github.com/mono/libgdiplus.git

cd libgdiplus

./configure –prefix=/opt/local

make

sudo make install

 

Mono-LLVM

Mono has a tweaked fork of LLVM. By default it will try to build x86 and x86_64 targets on Ubuntu x64 but the build will fail because there is no x86 runtime support installed.

cd ~/src/mono

git clone https://github.com/mono/llvm.git

cd llvm

git checkout mono

./configure –prefix=/opt/local –enable-optimized –enable-targets=x86_64

make

sudo make install

Mono with LLVM

Each official release of Mono is tagged in git. You should checkout the version that you want to build. In this case, I’m building Mono 3.2.5 with the LLVM and libgdiplus libraries we already built. Since there is no working version of Mono on the system, the very first time you build you need to do make get-monolite-latest which will pull down a minimal mono-based C# compiler to boostrap the build.

cd ~/src/mono

git clone https://github.com/mono/mono.git

cd mono

git checkout mono-3.2.5

export MONO_USE_LLVM=1

./autogen.sh –prefix=/opt/local –enable-llvm=yes –with-sgen=yes –with-gc=sgen

make get-monolite-latest

make EXTERNAL_MCS=${PWD}/mcs/class/lib/monolite/gmcs.exe

sudo make install

Assuming that all went well, you should now have a working build of mono 3.2.5 (or newer) in /opt/local/bin/ and executing mono –version should include LLVM: yes.

Depending on what you want to do with Mono, you may now want to build XSP (ASP.NET server, Apache module and FastCGI module for nginx) and/or F# 3.x.

XSP

The xsp2 server uses a .NET Framework 2.0/3.0/3.5 API and the xsp4 server provides a 4/4.5 API. The main tweak here is to set the PKG_CONFIG_PATH environmental variable so that the configure script can find mono in /opt/local.

cd ~/src/mono

git clone https://github.com/mono/xsp.git

cd xsp

git checkout 3.0.11

PKG_CONFIG_PATH=/opt/local/lib/pkgconfig ./autogen.sh –prefix=/opt/local

make

sudo make install

F# 3.1

cd ~/src/mono

git clone https://github.com/fsharp/fsharp

cd fsharp

git checkout fsharp_31

./autogen.sh –prefix=/opt/local

make

sudo make install

Advertisement

Filed under Uncategorized Tagged with , , , ,

Ximian is Dead, Long Live Xamarin

May 16, 2011 2 Comments

I was depressed when I heard that Attachmate disbanded the Mono team as a part of it’s acquisition of Novell but Miguel de Icaza has a lot of chutzpa. He has reformed his team in nothing flat and launched a new company to continue the development of Mono and its associated C#-based mobile toolkits, MonoToch (iOS) and  MonoDriod (Android) and Moonlight (Silverlight for Linux).

To make a long story short, the plan to spin off was not executed. Instead on Monday May 2nd, the Canadian and American teams were laid off; Europe, Brazil and Japan followed a few days later. These layoffs included all the MonoTouch and MonoDroid engineers and other key Mono developers. Although Attachmate allowed us to go home that day, we opted to provide technical support to our users until our last day at Novell, which was Friday last week.

…

Now, two weeks later, we have a plan in place, which includes both angel funding for keeping the team together, as well as a couple of engineering contracts that will help us stay together as a team while we ship our revenue generating products.

~Miguel de Icaza

All the best Miguel.

Filed under Uncategorized Tagged with , , , ,

Can Google Sidestep Oracle Patent Payouts with Mono/C#?

August 16, 2010 Leave a comment

android-monoOracle has sued Google over patent and copyright violations related to Google’s use of Java technologies in Android. Oracle acquired the Java IP as a part of its acquisition of Sun Microsystems. The details are somewhat different but this has the same general flavor as when Sun sued Microsoft over its non-conforming Java runtime and J++ language compiler. That lawsuit was based in contracts law because Microsoft did license Java from Sun and violated the terms of the license. In this case, Google has attempted to sidestep the licensing requirements of Java with their Dalvik VM. Once could reasonably argue that the technical basis was similar. Both Microsoft and Google want to achieve significant performance improvement and platform integration over a vanilla JVM at the cost of incompatibility with the Java standard. It’s not entirely clear that Davlik actually achieves superior performance, though. I have to wonder if the stack-based VM concept was incidental to the goal of making an end-run around J2SE runtime licensing requirements.

One intriguing—if a bit self-serving and improbable—proposal has been floated by Miguel de Icaza: Why not just replace Dalik with Mono, the free and open source implementation of Microsoft’s .NET? The Mono runtime is LGPLv2 and the class libraries are MIT licensed. Additionally the .NET Micro edition has been placed entirely under the Microsoft Public License which is a BSD-style license with an explicit patent grant. The Microsoft Community Promise explicitly indemnifies patent claims against anyone wishing to implement C# and the CLI and unlike Sun’s patent grant for Java, embrace-and-extend is OK—you can implement a superset of the C# and CLI features and you are still covered.

Google definitely has the wherewithal to migrate Android from Dalvik to Mono if they want to. They could make it a seamless transition and even migrate the bytecode of existing Dalvik (or Java) apps to IL. They could also provide a tool to migrate projects from Java language to C# as Microsoft did. Other implementations exist.

I think it would be pleasantly symmetrical if history repeated itself. Sun’s lawsuit put the kibosh on Microsoft using Java the way it wanted and essentially gave birth to C#, the CLI and the CLR. It would be ironic if history repeated and Android just adopted Mono as its runtime. The road is much easier to tread this time around because a fully open source implementation already exists and it has already been ported onto Android and bytecode-to-IL and Java-to-C# tools exist and are mature.

Filed under Uncategorized Tagged with , , , , , , ,

C# as Universal Smart Phone Programming Language?

February 24, 2010 Leave a comment

We started thinking about building a smart phone app to interface to PeopleMatrix. The obvious devices to support are BlackBerry, iPhone, Android and Windows Mobile. There is also Symbian but those devices are unusual in our primary market. Each one of these platforms has a totally different programming model:

  • BlackBerry –> Java ME + RIM libraries
  • iPhone –> Objective-C
  • Android –> Subset of Java 5 + Apache commons and  Android libraries
  • Windows Mobile –> C/C++ and .NET CF
  • Symbian –> Weird non-standard Symbian C++ variant and Qt

I just can’t envision anyone using their smartphone to interact with a sophisticated app on a screen the size or a postage stamp. That eliminates Blackberry and (many) Windows Mobile devices. Also, you have to prioritize developing for the device platforms that are growing. That means iPhone and Andoid. iPhone is very popular and Android has shown amazing growth.

The problem is that the development environment is totally different so that porting applications between Android and iPhone is a complete re-write. One ray of hope for leveraging code across these platforms is the Mono project. Novell is currently shipping a product called MonoTouch which compiles C# code into native binaries for the iPhone. The Mono guys also have Mono working on Android with proxy classes that call into the Android libraries. (In early testing Mono appears to out-perform Dalvik, too.)

If Mono on Android gets polished up like MonoTouch, that would make C# a first class programming language for a huge swath of the most exciting devices. The largest challenge for managing the codebase of an app is that it is very likely that each platform would require care to abstract access to platform-native APIs which would certainly include the GUI and other hardware interfaces.

Even so, I am watching Mono closely. Interesting times.

Filed under Uncategorized Tagged with , , , , ,

%d bloggers like this: