So apart NFC, what's new with Mono on FreeBSD? First, you wight have seen that mono 2.6 has been released for a while and is still not available in FreeBSD ports. The main reasons are:

• a thread concurrency problem which is still not solved but an ugly workaround have been found;
• a bug (well, a weird implementation) of the new built-in soft-mode debugger that makes it totally useless on amd64. A workaround have been found and in the meantime, the code has been updated upstream and will be part of mono-2.6.2 which will probably be released at the end of the month;
• the moonlight tools (e.g. the smcs.exe compiler) are still part of mono (read the code source is in mono-2.6.tar.bz2) but installed by moonlight (read the Makefiles with install targets are in moonlight-2.0.tar.bz2). This leads to some juggling which is in progress (read: I can build and install it on my system, Firefox segfaults when I browse a website with Silverlight contents, and configure fails in Tinderbox because it cannot find bison, which is however installed according to the logs).

I will not mention here the mono-basic-2.6.tar.bz2 source tarball that exists besides the moonlight-2.0.tar.bz2 tarball in the moon(light) source directory and the mono-basic-2.6.tar.bz2 source tarball in the mono-basic directory having different dates & checksums… Lot of fun to come I guess.

Once these various problems have been fixed, you can expect mono-2.6 to reach the ports, promptly followed by the last version of the MonoDevelop IDE which is quite lovely.

Last but not least, I am now a ports committer and flz@ is my mentor.

arthur# portsnap fetch
[...]
arthur# portsnap extract
[...]
arthur# cd /usr/ports/lang/mono
arthur# make -V PKGNAME
mono-2.4.2.3_1
arthur# make
[...]
if test -w ../mcs; then :; else chmod -R +w ../mcs; fi
cd ../mcs && gmake NO_DIR_CHECK=1 PROFILES='net_1_1 net_2_0 net_3_5 net_2_1' CC='cc' all-profiles
gmake[3]: Entering directory `/usr/ports/lang/mono/work/mono-2.4.2.3/mcs'
gmake profile-do--net_1_1--all profile-do--net_2_0--all profile-do--net_3_5--all profile-do--net_2_1--all
gmake[4]: Entering directory `/usr/ports/lang/mono/work/mono-2.4.2.3/mcs'
gmake PROFILE=basic all
gmake[5]: Entering directory `/usr/ports/lang/mono/work/mono-2.4.2.3/mcs'
gmake[6]: *** [build/deps/basic-profile-check.exe] Error 1
gmake[6]: Entering directory `/usr/ports/lang/mono/work/mono-2.4.2.3/mcs'
*** The compiler 'false' doesn't appear to be usable.
*** Trying the 'monolite' directory.
gmake[7]: Entering directory `/usr/ports/lang/mono/work/mono-2.4.2.3/mcs'
gmake[8]: *** [build/deps/basic-profile-check.exe] Error 138
gmake[8]: Entering directory `/usr/ports/lang/mono/work/mono-2.4.2.3/mcs'
*** The contents of your 'monolite' directory may be out-of-date
*** You may want to try 'make get-monolite-latest'
gmake[8]: *** [do-profile-check-monolite] Error 1
gmake[8]: Leaving directory `/usr/ports/lang/mono/work/mono-2.4.2.3/mcs'
gmake[7]: *** [do-profile-check] Error 2
gmake[7]: Leaving directory `/usr/ports/lang/mono/work/mono-2.4.2.3/mcs'
gmake[6]: *** [do-profile-check-monolite] Error 2
gmake[6]: Leaving directory `/usr/ports/lang/mono/work/mono-2.4.2.3/mcs'
gmake[5]: *** [do-profile-check] Error 2
gmake[5]: Leaving directory `/usr/ports/lang/mono/work/mono-2.4.2.3/mcs'
gmake[4]: *** [profile-do--basic--all] Error 2
gmake[4]: Leaving directory `/usr/ports/lang/mono/work/mono-2.4.2.3/mcs'
gmake[3]: *** [profiles-do--all] Error 2
gmake[3]: Leaving directory `/usr/ports/lang/mono/work/mono-2.4.2.3/mcs'
gmake[2]: *** [all-local] Error 2
gmake[2]: Leaving directory `/usr/ports/lang/mono/work/mono-2.4.2.3/runtime'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/usr/ports/lang/mono/work/mono-2.4.2.3'
gmake: *** [all] Error 2
*** Error code 1

Stop in /usr/ports/lang/mono.
*** Error code 1

Stop in /usr/ports/lang/mono.

A first look leads us on a wrong way (lane?): *** The compiler 'false' doesn't appear to be usable. This message is actually not an error message: the mono C# compiler (mcs(1)) is written in C# so some bootstrapping may be required if no version of mono is present on the system. The mono port adds EXTERNAL_MCS=false to MAKE_ARGS so that the mono port will be build exactly the same way regardless of an available mcs(1) in the path.

Hopefully, I tested on an old machine and could see that something was running for a couple seconds before failing. Ctrl+T in tcsh(1) told me more:

load: 0.08  cmd: mono 10910 [ksesigwait] 0.13u 0.10s 0% 24492k
load: 0.08  cmd: mono 10910 [ksesigwait] 0.13u 0.10s 0% 24964k

The good news is that some mono application is running. But wait, what is this ksesigwait state? A first look at the FreeBSD Kernel Cross Reference reveals that this state is defined in kern/kern_kse.c; the man page is kse(2); Wikipedia states KSEs were mandatory at introduction; made optional at kernel build time in the 7.0 release and removed from the 8.0 release with a compatibility library.

The second good news is that a 22MB mono.core file is written in the mcs directory.

arthur# gdb -q /usr/ports/lang/mono/work/mono-2.4.2.3/mono/mini/mono mono.core
Core was generated by `mono'.
Program terminated with signal 10, Bus error.
Reading symbols from /usr/local/lib/libgthread-2.0.so.0...done.
Loaded symbols for /usr/local/lib/libgthread-2.0.so.0
Reading symbols from /usr/local/lib/libglib-2.0.so.0...done.
Loaded symbols for /usr/local/lib/libglib-2.0.so.0
Reading symbols from /usr/local/lib/libintl.so.8...done.
Loaded symbols for /usr/local/lib/libintl.so.8
Reading symbols from /usr/local/lib/libiconv.so.3...done.
Loaded symbols for /usr/local/lib/libiconv.so.3
Reading symbols from /usr/local/lib/libpcre.so.0...done.
Loaded symbols for /usr/local/lib/libpcre.so.0
Reading symbols from /lib/libm.so.4...done.
Loaded symbols for /lib/libm.so.4
Reading symbols from /lib/libpthread.so.2...done.
Loaded symbols for /lib/libpthread.so.2
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0  0x2856bf2a in signalcontext () from /lib/libc.so.6
[New Thread 0x8319c00 (sleeping)]
[New Thread 0x8319800 (sleeping)]
[New Thread 0x8319600 (LWP 100098)]
[New Thread 0x82fd000 (runnable)]
[New LWP 100058]
(gdb) thread apply all bt

Thread 5 (LWP 100058):
#0  0x2856bf2a in signalcontext () from /lib/libc.so.6
#1  0x28527fc4 in pthread_mutexattr_init () from /lib/libpthread.so.2
#2  0x28303480 in ?? ()

Thread 4 (Thread 0x82fd000 (runnable)):
#0  0x285eb0ac in __vfprintf () from /lib/libc.so.6
#1  0x2855ff90 in vasprintf () from /lib/libc.so.6
[...]
#33814 0x081464b8 in mono_runtime_invoke (method=0x82fd81c, obj=0x0, params=0xbfbfe510, exc=0x0) at object.c:2401
#33815 0x0814785b in mono_runtime_exec_main (method=0x82fd81c, args=0x28657f60, exc=0x0) at object.c:3301
#33816 0x0814736c in mono_runtime_run_main (method=0x82fd81c, argc=2, argv=0xbfbfe74c, exc=0x0) at object.c:3089
#33817 0x080cdf7d in mono_jit_exec (domain=0x28653ee0, assembly=0x833c880, argc=3, argv=0xbfbfe748) at driver.c:924
#33818 0x080ce0e8 in main_thread_handler (user_data=0xbfbfe690) at driver.c:972
#33819 0x080cfc3a in mono_main (argc=6, argv=0xbfbfe73c) at driver.c:1647
#33820 0x08058f90 in main (argc=6, argv=0xbfbfe73c) at main.c:34

Thread 3 (Thread 0x8319600 (LWP 100098)):
#0  0x2852f5f3 in pthread_testcancel () from /lib/libpthread.so.2
#1  0x28527fc4 in pthread_mutexattr_init () from /lib/libpthread.so.2
#2  0x28303480 in ?? ()

Thread 2 (Thread 0x8319800 (sleeping)):
#0  0x28528097 in pthread_mutexattr_init () from /lib/libpthread.so.2
#1  0x28521ade in _nanosleep () from /lib/libpthread.so.2
#2  0x28521c42 in nanosleep () from /lib/libpthread.so.2
#3  0x081e32ca in collection_thread (unused=0x0) at collection.c:34
#4  0x28520449 in pthread_create () from /lib/libpthread.so.2
#5  0x285deecb in _ctx_start () from /lib/libc.so.6

Thread 1 (Thread 0x8319c00 (sleeping)):
#0  0x28528097 in pthread_mutexattr_init () from /lib/libpthread.so.2
#1  0x2852822b in pthread_mutexattr_init () from /lib/libpthread.so.2
#2  0x2852c839 in _pthread_cond_wait () from /lib/libpthread.so.2
#3  0x2852cd82 in pthread_cond_wait () from /lib/libpthread.so.2
#4  0x081e86d8 in _wapi_handle_timedwait_signal_handle (handle=0x1d05, timeout=0x0, alertable=0, poll=0) at handles.c:1605
#5  0x081e846e in _wapi_handle_wait_signal_handle (handle=0x1d05, alertable=0) at handles.c:1548
#6  0x08205f2e in WaitForSingleObjectEx (handle=0x1d05, timeout=4294967295, alertable=0) at wait.c:205
#7  0x081608a0 in finalizer_thread (unused=0x0) at gc.c:1061
#8  0x081806f0 in start_wrapper (data=0x8326380) at threads.c:623
#9  0x08200367 in thread_start_routine (args=0x832c230) at threads.c:286
#10 0x08223adf in GC_start_routine (arg=0x2865aec0) at pthread_support.c:1382
#11 0x28520449 in pthread_create () from /lib/libpthread.so.2
#12 0x285deecb in _ctx_start () from /lib/libc.so.6
#0  0x2852f5f3 in pthread_testcancel () from /lib/libpthread.so.2

Yes, you read it well, the thread 4 backtrace is 33820 frame long! Looks like we have a stack overflow... Since the problem occurs on FreeBSD 6 (where KSE is enabled by default) and not on FreeBSD 7 (where KSE is disabled by default) nor FreeBSD 8 (No KSE at all), it is likely to be related to the thread implementation.

Let's launched one more time gmake(1) and hit Ctrl+Z to suspend all when mono was filling-in it's stack in order to have some hints about the exact command being executed. Reducing it to a simple test is trivial, e.g.:

arthur# pwd
/usr/ports/lang/mono/work/mono-2.4.2.3/mcs
arthur# env MONO_PATH="$PWD/class/lib/monolite" ../mono/mini/mono --config ../runtime/etc/mono/config ./class/lib/monolite/mcs.exe
Bus error (core dumped)
arthur# 

Now we know what is being run. Let's get some info about this binary file:

arthur# ldd ../mono/mini/mono
../mono/mini/mono:
	libgthread-2.0.so.0 => /usr/local/lib/libgthread-2.0.so.0 (0x28304000)
	libglib-2.0.so.0 => /usr/local/lib/libglib-2.0.so.0 (0x28309000)
	libintl.so.8 => /usr/local/lib/libintl.so.8 (0x283c9000)
	libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x283d2000)
	libpcre.so.0 => /usr/local/lib/libpcre.so.0 (0x284c7000)
	libm.so.4 => /lib/libm.so.4 (0x284fc000)
	libpthread.so.2 => /lib/libpthread.so.2 (0x28512000)
	libc.so.6 => /lib/libc.so.6 (0x28537000)

pthread(3) list all thread libraries available on the system:

• POSIX Threads Library (libpthread, -lpthread)
• 1:1 Threading Library (libthr, -lthr)
• Reentrant C Library (libc_r, -lc_r)

On my FreeBSD 8.0-STABLE machine, ldd(1) reports (mono-2.6 instead of 2.4):

marvin# ldd `which mono`
/usr/local/bin/mono:
	libgthread-2.0.so.0 => /usr/local/lib/libgthread-2.0.so.0 (0x8008b4000)
	libglib-2.0.so.0 => /usr/local/lib/libglib-2.0.so.0 (0x8009b8000)
	libicui18n.so.38 => /usr/local/lib/libicui18n.so.38 (0x800b74000)
	libintl.so.8 => /usr/local/lib/libintl.so.8 (0x800dca000)
	libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x800ed3000)
	libpcre.so.0 => /usr/local/lib/libpcre.so.0 (0x8010cd000)
	libm.so.5 => /lib/libm.so.5 (0x8011fd000)
	libthr.so.3 => /lib/libthr.so.3 (0x80131c000)
	libc.so.7 => /lib/libc.so.7 (0x801434000)
	libicuuc.so.38 => /usr/local/lib/libicuuc.so.38 (0x80166e000)
	libicudata.so.38 => /usr/local/lib/libicudata.so.38 (0x80189f000)
	libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x80248e000)
	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x802699000)

So let's try to use libthr on FreeBSD 6. This can be achieved using libmap.conf(5): instead of /lib/libpthread.so(.2) we want to use /usr/lib/libthr.so(.2):

arthur# cat >> /etc/libmap.conf << EOT
libpthread.so.2  libthr.so.2
libpthread.so    libthr.so
EOT

then...

arthur# make
[...]
arthur# make tests
[...]
363 test(s) passed. 0 test(s) did not pass.
[...]
arthur# echo $?
0

\o/

More recently, I was happy to find out that it was not the case anymore: Banshee was simply unable to detect the CD-ROM anymore. Still not so cool: you were still unable to listen to an audio CD, not mentioning ripping it.

For some reason I cannot really figure out (I have spent quite some time in fixing Banshee for FreeBSD and giving it some love), I took a look at this problem.

Obviously, the first rusty part of the chain of tools involved with audio CD was MusicBrainz and more precisely musicbrainz-sharp (a client library for .NET / Mono). FreeBSD having it's own ioctls for managing CD drives, and musicbrainz-sharp having 3 concrete classes for managing such devices called DiscLinux, DiscWin32 and DiscWin32NT, a piece was definitively missing. With a great deal of inspiration, it was called DiscFreeBSD and provides bindings for almost everything referenced in sys/cdio.h. When instanced, this class reads the CD in the drive and computes an ID used to fetch information about the audio CD from the Internet.

Unfortunately, I could not test the library on a system one which it is supposed to work (read GNU/Linux) so I asked a friend of mine, Baptiste (Yes! It works!) [edit: 2009-11-10:12:04 he just told me he has a a-bit-better website where he is playing now...], to tell me how it goes and to help me make the library behave the same on GNU/Linux and FreeBSD. We quickly had some good results:

Yay! Tracks from Sopor Aeternus' album Les fleurs du Mal are being listed!

Unfortunately, it was not possible to listen to the CD nor rip it... Not so cool once more.

And here takes place the magic of GStreamer!

cd /usr/ports/audio/gstreamer-plugins-cdparanoia && make install

Now, Banshee can play and RIP audio CDs with a single mouse clic!

Playing Cinema Strange's The Astonished Eyes Of Evening...

And ripping it (progress in the bottom left corner)...

All this will be soon in your ports tree!

For those who can't wait, patches for musicbrainz-shap are in the project's trac: Add support for FreeBSD in MusicBrainzSharp.

I have just spent a while wondering why the size of some data structures in C# was wrong while writing bindings to the CD-ROM control features of the FreeBSD libc.

Considering the following code snippet:

struct msf {
	public byte unused;
	public byte minute;
	public byte second;
	public byte frame;
};
[StructLayout (LayoutKind.Explicit)]
struct msf_lba {
	[FieldOffset (0)] public msf msf;
	[FieldOffset (0)] public int lba;
	[MarshalAs (UnmanagedType.ByValArray, SizeConst = 4)]
	[FieldOffset (0)] public byte [] addr;
};
struct cd_toc_entry {
	byte unused1;
	public byte control_addr_type;
	public byte track;
	byte unused2;
	public msf_lba addr;
};
struct cd_sub_channel_media_catalog {
	public byte data_format;
	public int mc_valid;
	[MarshalAs (UnmanagedType.ByValArray, SizeConst = 15)]
	public byte [] mc_number;
};

We can compute the size of each structure (MSDN page about types size):

msf

A msf structure contains 4 members each of 1 byte long so the whole structure is 4 bytes;

msf_lba

This is not more than the union of a msf structure (4 bytes), an int (4 bytes) and an array of 4 byte (4 bytes), so it's 4 bytes long too;

cd_toc_entry

A cd_toc_entry structure is composed of an unused byte (1 byte), 2 data byte (1 byte + 1 byte), another unused byte (1 byte) and a msf_lba structure (4 bytes) so it is 1 + 1 + 1 + 1 + 4 = 8 bytes long;

cd_sub_channel_media_catalog

A cd_sub_channel_media_catalog structure starts with 1 byte (1 byte), followed by an int (4 bytes), and an array of 15 byte (15 bytes). The whole structure is therefore 1 + 4 + 15 = 20 bytes long.

These results can be checked using Marshal.SizeOf:

Marshal.SizeOf (typeof (msf)) = 4
Marshal.SizeOf (typeof (msf_lba)) = 4
Marshal.SizeOf (typeof (cd_toc_entry)) = 8
Marshal.SizeOf (typeof (cd_sub_channel_media_catalog)) = 24

So the cd_sub_channel_media_catalog structure it 4 bytes long more that expected. This really sounds like alignment problems in C. A quick search on the Interop with Native Libraries page on Novell's wiki does not give any info about such a problem. Switching the two first fields order fix the size (but of course breaks the workability) so it is definitively an alignment problem that takes place here.

After some search, I could find the StructLayoutAttribute.Pack Field (actually I could not find this piece of information using the MSDN search engine, I had to search on the web similar problems and find this one with a reference to Pack to find this page in the Microsoft .NET documentation).

Finally, the solution is to write this:

[StructLayout (LayoutKind.Sequential, Pack = 1)]
struct cd_sub_channel_media_catalog {
	public byte data_format;
	public int mc_valid;
	[MarshalAs (UnmanagedType.ByValArray, SizeConst = 15)]
	public byte [] mc_number;
};

The MusicBrainzSharp port to FreeBSD can go on!

Here comes DbLinq, which aims to provide linq to SQL for many DataBase systems. While this project is still considered experimental to some extends by its developers, I wanted to give it a try. Since it way quite a PITA, here are the details for building using DbLinq with mono.

Get DbLinq from the Subversion repository

The latest stable release is quite old, and the project page warns we recommend using the latest SVN HEAD, so checkout the code from the google code repository:

svn checkout http://dblinq2007.googlecode.com/svn/trunk/ dblinq2007

Open the solution in MonoDevelop (or your favourite editor) and edit each project options so that assemblies are signed with the DbLinq.snk key.

You can then compile all needed assemblies and the DbMetal utility.

Get the System.Data.Linq.dll assembly

This assembly is not yet in the stable mono releases. You can compile it from the mono trunk:

svn checkout http://anonsvn.mono-project.com/source/trunk/mcs
cd mcs && ./configure && gmake

The assembly for the 2.0 profile is then available as class/lib/net_2_0/System.Data.Linq.dll.

Start you project

Create a new project as usual and add any required references. For example, my project use PostgreSQL so I added the following assemblies:

• DbLinq.dll
• DbLinq.PostgreSQL.dll
• Npgsql.dll
• System.Data.dll
• System.Data.Linq.dll

Generate classes to access your DataBase

The DbMetal utility generate classes from a DataBase schema. Before using it, ensure that DbMetal.exe.config exists in the DbMetal.exe directory and if not, copy it from DbMetal/App.config. You can then use the utility to generate your code:

mono DbMetal.exe /conn:"server=localhost;user id=user;\
   password=password; database=db" /provider=PostgreSQL \
   /code:db.cs /pluralize

Add the generated db.cs to your project and start coding:

using System;
using Npgsql;

class MainClass
{
	public static void Main(string[] args)
	{
		string connStr = "server=localhost;user id=user; password=password; database=db";
		NpgsqlConnection conn = new NpgsqlConnection(connStr);

		using (Db db = new Db(conn))
		{
			foreach (Employees e in db.Employees)
			Console.WriteLine(e.Name);
		}
	}
}

The lang/mono port still has many patches to make mono build and run on FreeBSD, but still should change with mono-2.6: the mono trunk can now be build vanilla on FreeBSD.

So, what's coming next? Well, I have been working on splitting the deskutils/gnome-do-plugins in order to cut down a bit the *HUGE* amount of dependencies for building and running all plugins. Working on this proved that devel/monodevelop is somewhat ready to be committed in the FreeBSD ports tree, so expect at least these two packages to be available in the ports collection soon!

To finish, I want to thanks Florent Thoumie (flz@) for taking care of my Mono PR.

Mandatory screenshot:

Editing notes with FIXMEs and TODOs.

For more info and downloads, have a look to the Tomboy-Todo project's page.

svk is a decentralised version control system based on Subversion. It acts as a staging area between the repository and your local copy, making synchronisations and merges easy.

Preparing repositories

A tricky thing with mono is that it is likely to blow-up in your face each time you change the framework version. Hence, I decided to build ports with different mono versions to see which one is the best for production use.

In order to work with different versions of mono, I created as many working copies of the ports tree as needed. This was achieved this way:

$ svk mirror http://bsd-sharp.googlecode.com/svn/trunk //mirror/bsd-sharp
$ svk sync -a
$ svk copy //mirror/bsd-sharp //local/bsd-sharp
$ svk checkout //local/bsd-sharp bsd-sharp-latest
$ svk checkout //local/bsd-sharp bsd-sharp-mono-126

The bsd-sharp-latest directory will contain the latest mono version available (1.9.1 at the time of writing), while the bsd-sharp-mono-126 directory will hold mono at version 1.2.6.

Setting-up a Tinderbox

I already mentioned the tinderbox package building system. I will not detail here the complete setup of a tinderbox, please refer to the README file provided in the tarball for detailed instructions.

Creating Ports Trees

The first ports tree to create is an official ports tree, in sync with FreeBSD ports:

# cd ${pb}/scripts
# ./tc createPortsTree -p FreeBSD -d "FreeBSD ports tree" \
  -w http://www.freebsd.org/cgi/cvsweb.cgi/ports/

Each BSD# ports tree is then created using an user (i.e. custom) update script that merge local copies of the BSD# repository in the FreeBSD ports tree:

# cd ${pb}/scripts
# mkdir ../portstrees/BSD-sharp-latest
# ln -s /home/romain/BSD-sharp-update.sh ../portstrees/BSD-sharp-latest/update.sh
# ./tc createPortsTree -p BSD-sharp-latest -u USER

DRY with Hooks

The main problem with this setup is that all ports that do not depends on mono will still be compiled for each build and therefore we will lose a lot of time compiling the same software packages.

This can however be avoided using a post-port-build hook that copy successfully created packages of software pieces not depending on mono to other builds' package directory and update those ports status in the data-store:

# cd ${pb}/scripts
# ./tc updateHookCmd -h postPortBuild -c /home/romain/postPortBuild

Tinderbuild

The environment is ready! You can start playing:

# cd ${pb}/scripts
# ./tinderd

The tinderbox I setup is IPv6 only accessible at http://eddy.sigabrt.org (Not always up).