[Mono-dev] Platform independence of mono assemblies

[Jonathan Pryor]

"The perfect is the enemy of the good"
	- Voltaire

On May 18, 2011, at 5:53 PM, Christian Krause wrote:
> In Fedora, the assemblies are treated as architecture-dependent and so
> they (including the GAC) are put into %{_libdir} which is /usr/lib64 on
> x86_64 systems.
> 
> However, it seems to be the standard for mono to place the assemblies
> under %{_prefix}/lib/, regardless of the architecture.
> 
> As far as I know this decision was based on a statement from the mono
> developers ([1]), that although the C# assemblies are currently
> architecture independent, it can not be guaranteed that they will be
> forever. That is why Fedora treats C# assemblies as arch-dependent files
> and so they are installed on multi-arch x86_64 systems into /usr/lib64.

Not exactly. As Miguel mentioned, mono at the time required that AOT-compiled shared libraries be placed next to the assembly, e.g. for mscorlib.dll the AOT-compiled mscorlib.dll.so must be in the same directory.

However, no Linux distribution actually uses AOT-compiled assemblies (that I know of, anyway). Hence my quote: the feature is there, but it's rarely (never?) used, so using this as a reason to be different from openSUSE, Debian, Ubuntu, and the default build setup seems like chasing the perfect at the expense of the good.

This is also somewhat moot as Mono no longer requires that the AOT-compiled .so be next to the assembly, as it can instead look for assemblies in ~/.mono/aot-cache if the MONO_AOT_CACHE environment variable is set; see mini/aot-runtime.c!load_aot_module_from_cache [0].

A "proper" fix would likely involve altering the runtime so that other "well defined" platform-specific directories are checked for AOT .so's before JITing the assembly, but this apparently hasn't been important enough for anyone to actually implement (the above "nobody uses AOT" argument).

> As far as I know, the C# assemblies are indeed architecture independent
> (as defined by the CIL standard). There may be some corner cases where
> it is possible to explicitly write arch-dependent code, but these may be
> treated as bugs in the projects.

It _is_ possible to have platform specific assemblies. Not because the IL is platform specific (as you note), but because of Platform Invoke [1], which allows ~direct invocation of native code. Managed code may thus embody platform specific assumptions. For example, consider nanosleep(2) [2]:

	struct timespec {
		time_t tv_sec;
		long tv_nsec;
	};
	int nanosleep(const struct timespec* req, struct timespec *rem);

What's `time_t`? That can vary amongst POSIX implementations. What's `long`? That can (and will!) vary between ILP32 (32-bit linux; 32-bits), LP64 (64-bit Linux; 64-bits), and P64 (Win64; 32-bits) platforms.

A naive P/Invoke would be:

	struct Timespec {
		public int tv_sec;
		public int tv_nsec;
	}
	class NativeMethods {
		[DllImport ("libc.so")]
		public static extern int nanosleep (ref Timespec req, out Timespec rem);
	}

This is naive because it assumes that time_t is 32-bits in size, and `long` is also 32-bits in size; in short, this will only work on 32-bit platforms, and will fail in "weird" ways on 64-bit platforms.

This can be fixed, and as such treating the declaration as a bug to be fixed is valid:

	struct Timespec {
		public IntPtr tv_spec;
		public IntPtr tv_nsec;
	}

Using `IntPtr` instead of `int` results in the use of 32-bit values on 32-bit platforms, and 64-bit values on 64-bit platforms. This is thus portable between ILP32 and LP64 Linux platforms...and thus breaks on Win64. In this case we can declare that Windows is unsupported (which makes sense as Windows doesn't provide nanosleep(2) anyway, unless you use cygwin.dll).

However, we're still assuming that `time_t` is an integral value, which is valid on Linux but is not required by the standard [3]:

	"time_t and clock_t shall be integer or real-floating types."

In this case it still might not matter...as long as we have the size correct (a 32-bit float can still be read as a 32-bit int, it'll just look "weird"), but nothing stops some bizarre 32-bit POSIX platform from using a 64-bit double for time_t, which would invalidate the Timespec declaration.

Again, we can declare that the perfect is the enemy of the good and leave it as is...or we can involve native code to do the type conversions for us, which is what Mono.Posix.dll and libMonoPosixHelper.so do.

 - Jon

[0] https://github.com/mono/mono/blob/master/mono/mini/aot-runtime.c#L843
[1] http://mono-project.com/Dllimport
[2] http://linux.die.net/man/2/nanosleep
[2] http://pubs.opengroup.org/onlinepubs/009695399/basedefs/sys/types.h.html