[Mono-dev] Platform independence of mono assemblies

[Christian Krause]

Hi Jonathan,

thank you very much for the answer! Here are a couple of follow-up
questions:

On 05/19/2011 03:46 PM, Jonathan Pryor wrote:
> On May 18, 2011, at 5:53 PM, Christian Krause wrote:
>> 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.

So to summarize:
- C# / CLI assemblies are itself platform independent
- the pre-compiled AOT ELF binaries are platform dependent (but are not
in wide-spread use and there may be other options where to place them in
the future)
- interfacing native code can be done platform dependent or independent
(see below)

> 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.

;-)

Just to remove all uncertainties:

Is it the view of the mono developers, that the standard libraries from
the mono project interfacing the native libraries in an
platform-independent way?

If there would be a platform dependency left by accident, would this be
considered a valid bug report?

Would you also agree, that if 3rd party projects use platform-dependent
assemblies this should be treated as a bug which has to be fixed?

>> 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]:

Yes, that's aligned with my understanding of the various ways to
interface native code (
http://www.mono-project.com/Interop_with_Native_Libraries ) and their
respective levels of architecture independence.

Best regards,
Christian