JNA cannot load my dll under Windows 7 but works for Linux and Windows XP

[John Preston]

I have some code using JNA 3.5 that loads my DLL and calls the functions. It works if I compile and run under Linux or Windows XP. However when I take the same code and run it under Windows 7, with the same version JVM 1.7_17 it complains of not being able to find the dll. However when I look at the library name that is displayed in the error message I see that it gets a win32-x86 added before it. Can anyone say why is tis and how I can turn this off. Like I said it compiles and runs OK under Windows XP and Linux.

[Timothy Wall]

Is your windows7 64-bit? are you running a 64-bit JVM? you need to ensure that your DLL matches your JVM architecture.

The platform prefix ("win32-x86") is used when attempting to load the library from the classpath. If the DLL is found on PATH or jna.library.path, the classpath is never searched.

On May 22, 2013, at 6:53 AM, John Preston wrote:

> I have some code using JNA 3.5 that loads my DLL and calls the functions. It works if I compile and run under Linux or Windows XP. However when I take the same code and run it under Windows 7, with the same version JVM 1.7_17 it complains of not being able to find the dll. However when I look at the library name that is displayed in the error message I see that it gets a win32-x86 added before it. Can anyone say why is tis and how I can turn this off. Like I said it compiles and runs OK under Windows XP and Linux.
>

> --
> You received this message because you are subscribed to the Google Groups "Java Native Access" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to jna-users+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[John Preston]

No I'm running 32 bit Windows 7 and Windows XP in VirtualBox 4.2.12. The JVM is 1.7u17 32 bit. I cannot use the latest JVM because I'm using netbeans 7.3 and there is a problem with the C/C++ MinGW which I use for compilation running 1.7u21

[John Preston]

Progress. So it appears then that my call to  NativeLibrary.addSearchPath is ignored under Windows 7 as opposed to Windows XP. When I look through the error message:

org.netbeans.InvalidException: StandardModule:org.opennaa.impl jarFile: 

Z:\SourceCode\OpenNAA\reference\java\nbnaa\build\cluster\modules\org-opennaa-impl.jar:

 java.lang.UnsatisfiedLinkError: Unable to load library 'opennaa': JNA native support (win32-x86/opennaa.dll) not found in resource path 

 (C:\Program Files\NetBeans 7.3\platform\lib\boot.jar;

 C:\Program Files\NetBeans 7.3\platform\lib\org-openide-modules.jar;

 C:\Program Files\NetBeans 7.3\platform\lib\org-openide-util-lookup.jar;

 C:\Program Files\NetBeans 7.3\platform\lib\org-openide-util.jar;

 C:\Program Files\NetBeans 7.3\platform\lib\locale\boot_ja.jar;

 C:\Program Files\NetBeans 7.3\platform\lib\locale\boot_pt_BR.jar;

 C:\Program Files\NetBeans 7.3\platform\lib\locale\boot_ru.jar;

 C:\Program Files\NetBeans 7.3\platform\lib\locale\boot_zh_CN.jar;

 C:\Program Files\NetBeans 7.3\platform\lib\locale\org-openide-modules_ja.jar;

 C:\Program Files\NetBeans 7.3\platform\lib\locale\org-openide-modules_pt_BR.jar;

 C:\Program Files\NetBeans 7.3\platform\lib\locale\org-openide-modules_ru.jar;

 C:\Program Files\NetBeans 7.3\platform\lib\locale\org-openide-modules_zh_CN.jar;

 C:\Program Files\NetBeans 7.3\platform\lib\locale\org-openide-util-lookup_ja.jar;

 C:\Program Files\NetBeans 7.3\platform\lib\locale\org-openide-util-lookup_pt_BR.jar;

 C:\Program Files\NetBeans 7.3\platform\lib\locale\org-openide-util-lookup_ru.jar;

 C:\Program Files\NetBeans 7.3\platform\lib\locale\org-openide-util-lookup_zh_CN.jar;

 C:\Program Files\NetBeans 7.3\platform\lib\locale\org-openide-util_ja.jar;

 C:\Program Files\NetBeans 7.3\platform\lib\locale\org-openide-util_pt_BR.jar;

 C:\Program Files\NetBeans 7.3\platform\lib\locale\org-openide-util_ru.jar;

 C:\Program Files\NetBeans 7.3\platform\lib\locale\org-openide-util_zh_CN.jar;

 C:\Program Files\Java\jdk1.7.0_17\lib\dt.jar;

 C:\Program Files\Java\jdk1.7.0_17\lib\tools.jar)

I don't see the path to the libopennaa.dll that I set before loading the library. Is there some reason I should not see this under Windows 7 as opposed to Windows XP.

On Wednesday, 22 May 2013 06:35:00 UTC-5, Timothy Wall wrote:

[Timothy Wall]

Why aren't you just setting jna.library.path?

[John Preston]

Setting the jna.library.path is the same as adding the path via NativeLibrary.addSearchPath. I tried both and they work under linux and Windows XP. But I can't get the code to work under Windows 7. I can't figure out what I'm doing wrong.

[Timothy Wall]

ok, I'm able to reproduce this running a 32-bit JVM on win7.

[John Preston]

So I'm not going crazy.

[John Preston]

Could this be a java runtime version issue as I have had to stick with 7.0_17 instead of the latest due to some issues with mingw. I've tried to downgrade to 7.0_13 but the issue still remains.

[Timothy Wall]

I still am not seeing it, either with gcc(3)-compiled or msvc(10)-compiled libraries.

Try calling Native.open() directly with an absolute path to your library (or map the windows LoadLibrary call via JNA and call that), then look at the GetLastError result. That will distinguish between a path issue and simply not being able to load the library due to some linkage defect.

[John Preston]

Ok it seems the problem was related to some uninstalled other dll's on the new Windows 7 machine. My dll required bonjour which was not installed on the new machine and this was reported as an unable to find my dll. Now I have it working on XP and Windows 7 32-bit. Now my new problem is when I try and run it on a Windows 7 64-bit I get the same unsatisfied link error. I am using a 32 bit jvm jdk_7_25.

[John Preston]

Ok solved. The issue here was that some dll's that my dll references were not available as 32 bit dll's. There were installed in the system but there were 64 bit dll's and I had compiled my stuff to work with 32-bit ones.When I included the 32-bit ones in my dll's path everything worked.