Question

I have Visual Studio 2010 installed and have a project I got from someone else which I can build successfully without any errors. I get a Wrapper.dll, which I would like to access using JNA. I am using Win7 64-bit.

But I get the error: java.lang.UnsatisfiedLinkError: Unable to load library Wrapper : The specified module could not be found.

Wrapper.dll of course is in the correct folder and it is a 32-bit dll and my Java program also uses a JRE with 32-bit, so this is not the cause of the error.

I used DependencyWalker to check whether *.dlls are missing:

MSVCP80.DLL
MSVCR80.DLL
GPSVC.DLL
IESHIMS.DLL

And yes there are some missing. Can I conclude that the error is related with that these DLLs are missing? But why does Visual Studio compile correctly then and does not throw an error? How to solve this in order to access these functions in Wrapper.dll?

I also read that downloading dll s might not be the right thing to do! (I know that Wrapper.dll relies on another dll or sourcecode which was built in Visual Studio 2005, if that is of interest.)

EDIT:

I found out, that Wrapper.dll relies on three other dlls which probably were built on MSVS2005. These require the above mentioned DLL s (checked with dependencywalker) and I guess therefore Wrapper.dll also links them.

So what do I actually do to get rid of these old dll s? Would I need to build the other three DLLs with VS2010 or is this a problem which always will appear, meaning, that you need to copy paste old DLLs in order to use the precompiled Libraries which are dependent on those.

Is there a way, that the program would run on any other system as well without copy pasting these DLL s?

Answer 1

All required DLLs must be available to the system for loading. If you define jna.library.path, that is where JNA will look for the initially loaded DLL, as well as any dependent DLLs. In addition, java.library.path (which is essentially PATH) will be searched for dependent DLLs.

MSVS often uses paths in addition to PATH when building, debugging, and running code within that environment.

Solutions:

a) remove dependencies you don t really need; this may include telling MSVS to build your DLL differently

b) include non-system DLLs next to your custom DLL (or include their location in PATH/java.library.path)

EDIT

a) you can include the offending DLLs in the same directory as yours. this is fairly low impact on the target system, but if they are DLLs that are expected to be on any system, you shouldn t have to do so. It s preferable to adjust java.library.path so that all system DLLs are accessible.

b) you can recompile your dependent DLLs and be more careful about backward compatibility and explicit linkage. Depending on features used by the DLLs, though, you may not be able to remove the dependencies.

MSVC[RP]80.DLL are C and C++ runtimes, respectively; you may or may not be able to link against a previous version.

IESHIMS.DLL is part of IE and should be on the system, but likely in a path inaccessible to your program.

GPSVC.DLL has to do with group security policy, so it should be available on the system (modulo whenever the DLL was introduced).

友情链接