SharedLibLoadException
This exception is thrown when the shared library cannot be loaded. This indicates
that the library is not on the user's system, is not on the path, or perhaps has
a name that is different than expected. In other words, no library could be found
that matches the name returned by the sharedLibName property of this
exception.
These exceptions may be chained in cases where Derelict attempts to load a library using multiple names. An exception will be created for each failure and chained to the last created exception. If the library fails to load after all of the names have been attempted, then the last exception created will be thrown with all of the previous exceptions chained to it.
SymbolLoadException
This exception is thrown when a symbol cannot be loaded from a shared library.
This might indicate that the library is corrupt, or that it is a different version
than expected. In other words, the library exists on the system, but
no symbol could be found that matches the name returned by the symbolName property of
this exception. In some cases, it may be desirable to prevent this exception from being
thrown. You can learn how by reading about Selective Symbol Loading.
void Derelict_SetMissingSymbolCallback(MissingSymbolCallback callback)
[alias bool function(char[] libName, char[] symbolName) MissingSymbolCallback]
This function allows the client to set a callback that will be called when a
symbol cannot be found in a shared library. The name of the library will be passed
to the callback in the libName parameter and the name of the missing
symbol in the symbolName parameter. The client can use these parameters
to determine if Derelict should continue loading the shared library. If so, then
the callback should return true. If Derelict should abort loading and throw an exception,
the callback should return false. Note that the callback must be set before loading
the library(ies) you are interested in. You can read more about this feature in
the Selective Symbol Loading documentation.
By default, each shared library in Derelict is unloaded in a module destructor at program exit. This means you need not call the unload method on any loader yourself. However, conflicts can sometimes arise when you want to use Derelict with your own resource management scheme. In these rare cases, it's possible that your code may try call a function through one of Derelict's function pointers after a library has already been unloaded. For those situations, SharedLibLoader exposes a static method that disables automatic unloading of shared libraries. Once this method is called, it is the client's responsibility to call the unload method on any loader whose load method was successfully called.
The following code example shows how to use this feature.
// First, you must make sure to import derelict.util.loader. import derelict.util.loader; // In a function or method, make the following call. SharedLibLoader.disableAutoUnload(); // From this point on, you are responsible for calling // unload on any loader objects whose load methods were // successfully called before or after disableAutoUnload. // Derelict will not unload *any* shared libraries at all.