[Mono-devel-list] Proposal: Library Loading

[Jonathan Pryor]

On Tue, 2004-04-13 at 21:07, Vladimir Vukicevic wrote:
> On Tue, 2004-04-13 at 17:52, Jonathan Pryor wrote:
> 
> > 1.  What happens if there are multiple major versions of libfoo.so
> >     installed: libfoo.so.1 and libfoo.so.2?  Which gets loaded?  At
> >     present, whichever libfoo-devel package was installed, which may be
> >     ABI-incompatible with what the assembly was written against.  Oops.
> 
> What happens if I have one assembly that needs libfoo.so.1,
> and another that wants libfoo.so.2?

Then we're screwed. :-)

On the plus side, this can't happen on Windows since Windows doesn't
support versioned libraries...

I can't think of an adequate solution to this.  As I mentioned before,
DllImport doesn't provide a way to specify the library version to load,
so there's no way for the managed code to specify which version it
requires.

I would suggest that we lobby Ecma extend the CLI standard: 

	class System.Runtime.InteropServices.DllImport {
		// ...
		public String LibraryVersion {
			get;
			set;
		}
	}

It's a string so that arbitrary version numbers can be used.  Mac OS X
frequently uses letters for versions (A, B, etc.), and other libraries
may include non-numeric characters in their version strings (rare, but
possible).

This would allow a CLI assembly to specify which library version to
load, permitting multiple different library versions to be loaded
simultaneously.

> The conf.d scheme seems to break
> down in that case (though arguably no worse than the current scheme).
> I don't mind the .d scheme, but I'm not really sure what it solves;
> the runtime could just as well know to look for libfoo.so.*, and
> pick the highest number that it finds, no?

This wouldn't necessarily work, as there is NO guarantee that different
major versions will have ANY compatibility.  Take GTK+ for example: the
only guarantee they're willing to provide is that everything in 2.x will
be API and ABI compatible; 3.x may not (and likely WILL NOT) be
compatible with 2.x.

So, N years from now, when GTK+ 3.x is released, we CANNOT load
libgtk.so.3 when an app requiring libgtk.so.2 is loaded.  Doing so
potentially puts the entire process at risk.

(In the ideal case, we'd just get MissingMethodExceptions, but if a
function exists but the number of arguments has changed, it's possible
that GTK+ would improperly access a parameter, corrupting memory, and
causing no end of pain.  Furthermore, reproducing this issue would be
non-trivial; we'd have to know that the user installed GTK+ 3.x and ran
a GTK+ 2.x-using app, which may not be immediately obvious.)

This is what I was attempting to answer: how do we know which library
version to load?  We might not be able to support loading all potential
library versions, but we can AT LEAST make sure that we'll load the
library that the assembly was written against, providing some measure of
sanity and safety.

 - Jon