[Mono-list] DllImport and modifying library search path

[Robert Jordan]

Hi,

On 11.02.2011 08:26, Uli Hertlein wrote:
> Now, to pickup the correct shared library I thought I'd prefix the the respective search path
> (LD_LIBRARY_PATH on Linux, DYLD_LIBRARY_PATH on OS X, and PATH on Windows) with this directory.
> This is then set using 'Environment.SetEnvironmentVariable("LD_LIBRARY_PATH", dllSearchPath)'

You're probably calling one of the p/invokes too close
to SetEnvironmentVariable (called either directly or indirectly).

If you really want such a fragile hack (it depends on the
order and the moment a method is JITed), you should compute
the variable that keeps the OS and bitness "far away" from
the first p/invoke call.

As Alexander wrote: in some static constructor, preferably
of another class.

Please consider using DLL maps (see "man mono-config"):

<configuration>
<dllmap dll="Sdk" target="libSdk32.so" os="linux" cpu="x86" />
<dllmap dll="Sdk" target="libSdk64.so" os="linux" cpu="x86-64" />
<dllmap dll="Sdk" target="libSdk32.dylib" os="osx" cpu="x86" />
<dllmap dll="Sdk" target="libSdk64.dylib" os="osx" cpu="x86-64" />
</configuration>

Since MS.NET does not understand these elements, you must either
have a per target .exe.config file or move the p/invoke stuff
to its own assembly and configure it with its .dll.config.

Note that this does not solve the 32 vs. 64 bit issue under MS.NET,
so your mileage may vary.

The recommended way is to use the same native dll name under
all platforms and decide at deploy time what to install.
If this is not possible, then consider setting these
environment variables from a launching script.

Anything else is just a huge hack and big waste of time, IMO.

Robert