0

This question is kind of similar to Q1 and Q2.

My Java code, which uses JNA to load a native library, goes like this:

69.    Print.good("found file: " + libraryPath);
70.    if( System.getProperty("os.name").toLowerCase().contains("win") ) {
71.        final String search_path = FileFinder.getParentDirPath(libraryPath);
72.        NativeLibrary.addSearchPath("libReliableServerNative", 
73.               search_path );
74.        Print.good("Added search path: " + search_path);
75.        System.setProperty("java.library.path", search_path);
76.        nativeLib = (NativeLib) Native.loadLibrary("libReliableServerNative", CTest.class);
        }

My terminal output, which prints the line number and library file location, goes like this:

++  Thread "main": Core_Reliable.Stupid_Client_UDP_Reliable.<clinit>(Stupid_Client_UDP_Reliable.java:69)
++  found file: C:\Users\HOLLYWOOD\Documents\NetBeansProjects\ReliableServerMadeUnreliable2\build\classes\libReliableServerNative.dll

++  Thread "main": Core_Reliable.Stupid_Client_UDP_Reliable.<clinit>(Stupid_Client_UDP_Reliable.java:74)
++  Added search path: C:\Users\HOLLYWOOD\Documents\NetBeansProjects\ReliableServerMadeUnreliable2\build\classes

java.lang.UnsatisfiedLinkError: The specified module could not be found.

    at com.sun.jna.Native.open(Native Method)
    at com.sun.jna.Native.open(Native.java:1759)
    at com.sun.jna.NativeLibrary.loadLibrary(NativeLibrary.java:260)
    at com.sun.jna.NativeLibrary.getInstance(NativeLibrary.java:398)
    at com.sun.jna.Library$Handler.<init>(Library.java:147)
    at com.sun.jna.Native.loadLibrary(Native.java:412)
    at com.sun.jna.Native.loadLibrary(Native.java:391)
    at Core_Reliable.Stupid_Client_UDP_Reliable.<clinit>(Stupid_Client_UDP_Reliable.java:76)
Exception in thread "main" Java Result: 1

^ You see that on line 76 in my Java code, Native.loadLibrary throws an UnsatisfiedLinkError. ^

  1. I ruled out the possibility that I was mixing up 32 bit and 64 bit libraries because I compiled the native library and the Java code on a 32 bit Windows machine with 32 bit Java, and specified the "-m32" command line parameter for gcc, which should output a 32 bit dll. For native compilation, I used cygwin.

  2. I also ruled out the possibility that the library could not be found because when that was the case I got "java.lang.UnsatisfiedLinkError: Unable to load library" instead of the above "java.lang.UnsatisfiedLinkError: The specified module could not be found."

I think that what is going on is "that it could not be loaded... that the dll was missing some dependencies." But the native library (libReliableServerNative.dll) is nothing more than a single C file with no dependencies other than the C standard library.

Full dependencies for libReliableServerNative:

#include<stdio.h> //printf
#include<string.h> //memset
#include<stdlib.h> //exit(0);
#include<arpa/inet.h> // inet_aton
#include<sys/socket.h> // unix socket
#include <unistd.h>
#include <netinet/in.h>

Do you have any idea why this is happening?

* Update * The Unsatisfied Link Error went away when I put cygwin1.dll in the jna path.

My problem now is that I am not getting any error messages. The native method never gets called - no printf statements from the native code appear, but the program doesn't terminate or throw any exceptions. The java statements after the call to nativeLib.myFunction() don't get executed.

Community
  • 1
  • 1
  • For item 1), that does not prove or disprove what the bitness of the library is. To know for sure what you have, either use `dumpbin.exe`, or a utility such as Dependency Walker http://www.dependencywalker.com. The other possibility you didn't mention is that you may have an older version of the library lurking around somewhere, and this is the version that is being picked up by Java. – PaulMcKenzie Aug 03 '15 at 02:46
  • When I load a dll that was compiled with cycgwin, is it dependent on a separate file whose name is "cygwin.dll", or is that included in libReliableServerNative.dll? –  Aug 03 '15 at 03:06
  • I have never compiled the thing on ANY PC other than Windows x86 - the probability of it being a 64 bit dll file is virtually zero. Also, I have made zero changes to the source code. Only one version exists. –  Aug 03 '15 at 03:34

1 Answers1

0

I got it working. If you compile with cygwin, you have to put cygwin1.dll in the resource path.

  • Compile with the mingw compiler to omit the cygwin dependency. It may require a few source code tweaks, but you'll get something more akin to what the MS compiler would generate and no cygwin dependencies. – technomage Aug 03 '15 at 11:37
  • I don't mind having the dependency on the dll file - It's just one dll file. My problem now is that I am not getting any error messages. The native method never gets called - no printf statements from the native code appear, but the program doesn't terminate or throw any exceptions. The java statements after the call to nativeLib.myFunc() don't get executed either. –  Aug 04 '15 at 05:28