[Mono-devel-list] [patch]Patch DllNotFoundException triggered for missing unmanaged libraries

[Mark Treiber]

I'd like to post in support of this patch.  I've spent the past day 
trying to track-down the cause of a DllNotFoundException in beta3 that 
turned out to be cause by specifically the same problem quoted below.  
Had this information been present it would have same me a lot of time 
since the problem is not with the Dll, the problem is with the linking.

Although a better solution might be to throw a DllLinkingErrorException 
derived from DllNotFoundException but this probably deviates from the 
standards but it would be a lot of help to many people.

Thanks Denis for posting this solution (even if it never goes into 
mono).

Mark.

-----Cut and paste from archives but the original message is below ---
Originally:
Denis Gervalle   dgl at softec.st
  Wed, 16 Jun 2004 09:21:20 +020

This is a multi-part message in MIME format.
--------------080908080209030207070604
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

I am probably loosing my time posting this patch, but for the case that
all previous versions have been ignored by mistake, here my updated
patch for beta3 that improve DllNotFoundException message when unmanaged
library, dependancy of unmanaged library or function are missing.

For those who wonder why I have made this patch and have missed previous
story, I append the story again here under.
Hope that this _last_ one will be considered for CVS check in. If any
improvement is needed for ci, please ask!

Denis Gervalle
SOFTEC sa
http://www.softec.st

The old story :
We have written this patch (and enhance it latter) after seaching hard
in the dark why a dynamic library next to our mono assembly is
presumably not found (DllNotFoundException) by mono.
The attached patch (based on the beta release) modify the triggered
exception when MONO_DEBUG is defined to provide a larger error message
corresponding to the joined error message of all tries done using
g_module_open() (opposed to the actual situation which only report the
last tried name). Here is a sample:

Unhandled Exception: System.DllNotFoundException: Trying libsample.so:
libsample.so: cannot open shared object file: No such file or directory
==> Trying ./libsample.so: ./libsample.so: cannot open shared object
file: No such file or directory ==> Trying sample.so:
libdependancy.so.0: cannot open shared object file: No such file or
directory

This patch also provide a detailled error report of missing entry points
in unmanaged library using the same technique. Another sample:

Trying 'libsample.so': libsample.so: cannot open shared object file: No
such file or directory ==> Trying ./libsample.so: Found ==> Searching
function 'mysymbolA': 'mysymbolA': mono: undefined symbol: mysymbolA ==>
Searching function 'mysymbol': 'mysymbol': mono: undefined symbol: 
mysymbol

This patch takes care of mint issues and mono pinvoke-wrapper issues.
For the latter, each exception messages are allocated permanently on the
heap since the exception is triggered by the wrapper code for each call
to a function from the missing library (and not during the loading
phase). This is why MONO_DEBUG is required to activate the code, since
it could "leak" memory if a lot of missing library are tried.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 3768 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20040619/5cfb9e75/attachment.bin