First of all, thanks for your reply. It have been really productive.
Some issues about your reply:
Your fundamental problem is that you're targeting Windows XP.
Ha ha only serious. (A colloquialism for "that's funny, but I'm serious
too...")
The slightly longer explanation is here:
http://www.mono-project.com/Interop_with_Native_Libraries#Windows_DLL_Search_Path
The real explanation is that Win32 is broken when it comes to supporting
multiple different versions of the "same" library. Absolutely,
fundamentally, *broken*. More to the point, it doesn't support this AT
ALL -- you can only have ONE version of any given library in use at any
point in time.
Win32 has three issues you're running into:
1. No built-in versioning support for libraries, as noted above.
Which is to say, if you load C:\Windows\System32\OLE32.dll, you
can't say that you want version 1 or version 2 of that library,
you get whichever version is at C:\Windows\System32\OLE32.dll.
2. This doesn't mean you can't have multiple different versions
installed. It just means that each different version needs to
reside in a different directory, which leaves you the option of
(a) always specifying a full (or relative) directory for your
library, or (b) accepting the default path and placing your library
into an appropriate location.
So if you didn't like Microsoft's OLE32.DLL, you could place a copy
into your application's directory, and *that* one would get loaded.
Alas, this means you can have the scenario you're describing, where
both mono and your app bundle glib. This is unfortunate, because of
issue (3).
3. Win32 doesn't keep track of the full path name to a library. It
only remembers the basename of the library.
Translation: If you LoadLibrary() C:\mono\glib.dll, Win32 will know
that it's loaded "glib.dll". If you then LoadLibrary()
C:\yourapp\glib.dll, Win32 will hand you back a handle to
C:\mono\glib.dll, because they both share the same basename
(glib.dll) -- C:\yourapp\glib.dll is NOT loaded.
Win32 doesn't operate on full paths. This is a feature (in certain
contexts, anyway -- it's what allows you to provide your own version
of OLE32.dll, or any other system library, and have it be used).
So, to answer your questions...
On Thu, 2005-06-09 at 19:23 +0200, Francis Brosnan Blázquez wrote:
* Any application which p/invokes libraries that are also provided by
mono must compile its native dll versions against the mono dll or it
is posible to compile these ones against, for example, a glib not
provided by the mono installer?
Is it possible? Yes. But to use your version of glib and not mono's
version, you'd need to alter the library search order for mono to ensure
it loads your version of glib and not mono's.
This probably is bad, because it will effect every application started
with mono, and your glib might not be compatible with mono's glib, which
would (likely) kill mono instantly.
So it's possible, but it's not advisable. :-)
Plus, it'll use extra disk space, so it would be nicer to use mono's
glib anyway...
The space impact that may have including several libraries using
different names don't
worry us. But setting a dependency against the mono libraries, such as
libglib-2.0, force
us to run over Mono and only over it. As you pointed following, the
library renaming
could be a solution to be able to run on top of Mono and microsoft .NET
runtime.
Alternatively, name your glib.dll with a different basename, e.g. af-
arch-glib.dll, and rebuild all your libraries against this basename.
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?
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 to
load 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?
* What happens if the mono runtime detects a P/Invoke over a library
A.dll which depends on B.dll and then another P/Invoke over the
library C.dll which depends on B'.dll knowing that B.dll and B'.dll
are the same library but not the same file?
Mono isn't in control of library loading, Win32 is. (Mono uses GLib's
g_module API, which in turn uses LoadLibrary().)
So, what would Win32 do? It would load A.dll (as found through the
normal DLL search path), would look for and load B.dll (ditto), and when
C.dll was loaded it would see that B.dll was already loaded, and not
load a new one, so C.dll would get the *first* B.dll that was ever
loaded.
In short, don't do that. :-)
(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.
- Jon
Thanks Jon,
- Francis
_______________________________________________
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
