[Mono-list] P/Invoke, Mono, .NET and Windows XP funny platform

[Jonathan Pryor]

On Mon, 2005-06-13 at 16:30 +0200, Francis Brosnan Blázquez wrote:
> About the library renaming issue.
> 
> Renaming library basename could help us to find a solution to build 
> application that can run on top of mono and .NET runtime ensuring the
> libraries the af-arch framework relies on will allways be loaded using
> the dll version we have used (appending the "af-arch-") on develop
> stage.
> 
> My question is: Could this confuse the windows dinamic library loading 
> to load a library called glib.dll and another one called af-arch-
> glib.dll both exporting the same symbols?

No.  Win32 is less flexible than ELF (which has its pros and cons).  ELF
will link an exported symbol from *any* library to any symbol import
that exists, which is rather useful -- it allows you to use LD_PRELOAD
to replace the GTK+ file selector without recompiling any apps (as was
occasionally done before GTK+ 2.4).

Win32, and "bi-level" Mach-O libraries (I forget the correct term, but
they're the recommendation for Mac OS X >= 10.2) don't have this
flexibility; instead, they require that a symbol come from a
specifically-named library.  In practice this is similar to C++/C#
namespaces or Java packages: you can have several different Foo classes,
but as long as they all reside in a different namespace/package, there
are no problems -- a class loads whatever it was compiled against.

This reduces any external flexibility (LD_PRELOAD has no equivalent
under Win32), but increases sanity (if you have a plugin that brings in
a DLL with the same symbols as some dependency of yours, there is no
conflict as long as the DLLs have different names; consider also any
versioning issues -- you don't need to worry about adding a symbol which
might be present in a different library, since the actual symbol name is
"tied" to the library name).  This is why there can be N different C
runtime libraries without conflict (msvcrt.dll, cygwin1.dll, whatever
Borland's compiler needs...).

> In other words, while running applications using .NET and doing
> P/Invoke over the af-arch-glib.dll the LoadLibrary will find it with
> no problem as well the Mono enviroment will do but, in the case of
> Mono, it have the glib.dll already loaded exporting the same (or
> mostly) symbols leading to have loaded into memory two version for the
> same entry point.
> 
> Using as follow [DllImport("af-arch-glib")] will ensure the .NET
> runtime as well as Mono toload the af-arch-glib.dll library. But will
> this also guide both runtimes to differenciate the symbols exported
> from glib.dll and those ones from af-arch-glib.dll?

Yes, for the reasons stated above.

<snip/>

> >(I'm not entirely sure why this works for you on Linux either, unless
> >you depend on a different version of glib than mono does, in which case
> >you'd bring in a different .so-name.  However, given that Linux/ELF
> >doesn't require a symbol to come from a given library, and instead
> >matches a symbol reference to ANY MATCHING SYMBOL within the address
> >space, I fail to see how, if B.so.2 is already loaded, when C.so.1 is
> >loaded and brings in B.so.3, you could ensure that C.so.1 actually uses
> >the functions in B.so.3 and not B.so.2, since the dynamic linker should
> >find the B.so.2 symbols first...  Madness, I say. :-)
>
> Well, what is happening is that we use Debian ;-). As other Linux
> distributions, the libraries dependecy is handled by the package
> system avoid you lot of problems. Libraries dependencies are set to
> the same for both mono and af-arch, but, libglib and libxml are not
> bundle as part of the mono package as opposed to windows platform.

In other words, your app uses the same dependencies as mono, not a
different version, which makes for a different (and simpler!) scenario
than your Win32 build. :-)

 - Jon