[mono-packagers] The $(prefix)/lib vs $(libdir) argument

[Jonathan Pryor]

So, to further muddy the waters...

CIL (as produced by vbnc, gmcs, booc, etc.) as located within .dll
and .exe files are *conceptually* platform-independent.  In theory, it
is fully platform independent, except for the minor issue of P/Invokes
(below).  This is what miguel was likely referring to with suggesting
that IL code should be in $prefix/share, which I would normally agree
with.

The JIT is a complete non-sequitur here, as the JIT produces code at
runtime.  Specifically, if we did install IL into /usr/share, you could
have *both* mono32 and mono64 programs running the same IL code.  The
JIT isn't a problem.

The problems are twofold:

1. P/Invokes: P/Invoke methods & classes/structures used by P/Invokes
usually refer to fixed-size data types.  This is often fine, e.g.
getpid(2) is unlikely to return anything other than a 32-bit integer on
platforms we care about.  This *can* be problematic with anything
dealing with C/C++ variably sized types such as `long` (which is 32-bits
on ILP32 platforms like Linux & Win32, 64-bits on LP64 platforms like
Linux & most Unix platforms, and 32-bits on P64 platforms like Win64).

It is possible to write platform-agnostic IL that uses P/Invokes, but it
is also very easy to make a mistake, e.g. by declaring fseek(3) to use
an `int offset' parameter, thus tying it to 32-bit platforms.

If code is properly written, this shouldn't be an impediment to placing
IL into /usr/share.

2. Ahead-Of-Time code (`mono --aot`).  The JIT can pre-compile IL into
native machine code, and (obviously) this native code is specific to the
target machine.  Furthermore:

i. the generated native code (a .so file) is placed into the same
directory as the "source" IL.

ii. The .so filename does NOT currently have any architecture
information encoded within it.

Thus, the use of AOT functionality should nix the idea of /usr/share, as
e.g. /usr/share/mono/2.0/mscorlib.dll.so could only be for a single
architecture.

However, this likely could be fixed (e.g. by placing the .so files for
GAC'd assemblies within $(libdir)), and no one (afaik) uses --aot for
the mono-provided assemblies anyway, so this concern is as theoretical
as the P/Invoke issue. :-)

So, the waters sufficiently muddied, I don't see any reason why mono
packages for .dll files could not be .noarch, AS LONG AS --aot is not
used with them (which usually isn't the case).

The case-in-point example for this is openSUSE, where on 64-bit
platforms the mono-core package provides /usr/lib/mono/2.0/mscorlib.dll
(and the platform /usr/bin/mono and /usr/lib64/libmono.so) and a
mono-core-32bit package provides /usr/bin/mono32 and /usr/lib/libmono.so
(and hardly anything else):

        jon at lina:tmp$ rpm -ql mono-core-32bit
        /usr/bin/mono32
        /usr/lib/libMonoPosixHelper.so
        /usr/lib/libikvm-native.so
        /usr/lib/libmono.so
        /usr/lib/libmono.so.0
        /usr/lib/libmono.so.0.0.0

Now, for this platform there would be no impediment to placing the .dll
files into /usr/share (aside from inertia and time), as it's ~no
different from always placing .dll files into $prefix/lib -- there will
only ever be one set of .dll files, ever, and NOT one set per mono JIT
architecture.

(Obviously, if you change the requirements things will change -- if AOT
were actually used, openSUSE may then require two sets of .dll files,
one per architecture, or (preferrably?) a better AOT setup so that AOT
files aren't placed in the same directory as the "source" IL code...)

 - Jon

On Sat, 2008-11-29 at 18:03 +0100, Zoltan Varga wrote:
> Hi,
> 
>   I have no idea whenever $(prefix)/lib or $(libdir) is the correct
> approach, but the assemblies
> shipped with mono _are_ platform independent, whenever they are
> 'built' using a JIT or
> not. For proof, they can be copied to any other architecture supported
> by mono, like arm
> or itanium, or even windows, and they will run just fine there.
> 
>                              Zoltan
> 
> On Sat, Nov 29, 2008 at 3:21 PM, Paul <paul at all-the-johnsons.co.uk> wrote:
> > Hi,
> >
> > I know this argument has been going on for a while, but I feel it's now
> > something that really needs to be resolved across all of the mono stack
> > (and dependencies).
> >
> > Many many moons ago, Miguel said that as CIL is completely agnostic as
> > to what it is on, that everything mono related should really be
> > in /usr/share. Noises were made, but nothing really much happened. There
> > is logic in using /usr/share, but nothing completely overwhelming.
> >
> > There is then the argument that all mono packages should be .noarch.
> > This really is a non-starter, I'll explain below.
> >
> > The current situation is that by default, mono is installed to
> > $(prefix)/lib with scripts from $(prefix)/bin pointing to the CIL
> > binaries or libraries. The only problem is that if you're compiling
> > using JIT, then binaries (and libraries) are targetting a particular
> > architecture (albeit x86, PPC, PPC64, x86_64 or any other processor
> > type) and are therefore incorrectly polluting the /usr/lib directory
> > which on non-x86 platforms is there for *purely* 32 bit libs.
> >
> > This means that for mono to be correctly packaged for non-x86 platforms,
> > all of the makefiles, .pc files and anything else like that has to
> > patched to use $(libdir) rather than $(prefix)/lib. Okay, it probably
> > doesn't seem like much, but given the size of mono (and associated
> > packages), patching becomes a major ball ache!
> >
> > While I understand that not every distro builds the JIT compiler, using
> > $(libdir) would mean that for the sake of argument, files are correctly
> > installed to the correct libdir. I also don't know how Windows is
> > handled with respect to this.
> >
> > Using JIT also makes anything built using it a non-noarch package.
> >
> > There is the flipside in that there is currently no fixed guideline of
> > where to place files for mono. Some mono packages use $(libdir) in the
> > makefiles (mono-basic is an example of this), some mix and match (makes
> > a bloody awful mess of things) and some just use $(prefix)/lib.
> >
> > I have a whole raft of patches available if we go over to $(libdir) - I
> > mean lots of them, probably coming up to 100k worth, but we certainly
> > need to get this sorted as it's starting to get ridiculous.
> >
> > TTFN
> >
> > Paul
> > (long time mono user and mono packager for Fedora)
> > --
> > Sie können mich aufreizen und wirklich heiß machen!
> >
> > _______________________________________________
> > mono-packagers-list mailing list
> > mono-packagers-list at lists.ximian.com
> > http://lists.ximian.com/mailman/listinfo/mono-packagers-list
> >
> >
> _______________________________________________
> mono-packagers-list mailing list
> mono-packagers-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-packagers-list