[news.eclipse.technology.equinox] Re: Can't find dependent libraries of

[Alex Blewitt <alex_blewitt@xxxxxxxxx>]

Firstly, using os/ws/arch is a deprecated way of referring to DLLs. For OSGI stuff,they should be in the root (preferably provided by a fragment, so you can partition the OS stuff out into different fragments).

Secondly, the problem is that whilst Eclipse knows the search directory to look for these things, Windows doesn't. In this case (presumably) module_java.dll refers to module.dll so the resolution goes like:

Eclipse: Hey, Windows, can you have a look for module_java? I'm pretty sure I've seen it in os/win32/x86 somewhere.

Windows: No problem. Oh look, here it is (loads dll). Hang on a sec, it turns out that module_java.dll needs module.dll. I'll look for it in the only place I know; the PATH. Nope, not in /windows/system32, nope, not in /windows/dll/ ...

So the problem is that whilst Eclipse tells windows where to load the original DLL from, Windows isn't smart enough to look in exactly the same place for dependent libraries. (Putting '.' on the path doesn't help either, because '.' is the directory from where you launched Eclipse.exe).

However, all is not lost. You can give Windows a helping hand:

Eclipse: Hey, Windows. Can you load 'module.dll' for me? It's in os/win32/x86.

Windows: Sure, no problem.

Eclipse: Hey, Windows. Can you load 'module_java.dll' for me? It's in os/win32/x86.

Windows: Sure. Hang on, it turns out module_java.dll depends on module.dll. Fortunately, I've already loaded it before so I'll just use it.

In a nutshell;

System.loadLibrary("module");
System.loadLibaray("module_java");

and don't forget to get rid of the os/win32/x86 directory structure ...

Alex.