[Mono-devel-list] Proposal: Library Loading

[Vladimir Vukicevic]

On Tue, 2004-04-13 at 18:25, Jonathan Pryor wrote:
> On Tue, 2004-04-13 at 21:07, Vladimir Vukicevic wrote:
> > 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...

Yep, but windows users are already screwed to begin with.  (Not because
they're using windows, mind you, but because this whole mess has come
about because of the lack of versioning of non-managed dll's in
windows.)  For windows, you just ship the DLLs you need with your app.

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

I like this; but probably not a realistic thing in time for 1.0.

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

That's why there is no libgtk.so, there is libgtk-1.2.so and
libgtk-x11-2.0.so :)  But I agree, we can't load libgtk.so.3 -- so if
there's a mapping for "gtk" in the conf.d directory to libgtk.so.3, then
that app is going to get libgtk.so.3 anyway.

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

Not unless each assembly explicitly specifies what library versions it
wants.  Maybe we can add a mono-specific extension to AssemblyInfo, if
not a MonoDllImport?  I think a per-assembly solution is the way to go
here, instead of a system-wide one.  The system-wide default could be
the simple largest-installed hack.

	- Vlad