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
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
