Windows UnsatisfiedLinkError #636
Comments
|
JNA version? run “java -jar jna.jar”. Extract the jnidispatch.dll and ensure it’s on your PATH to avoid the automatic unpack step (just for testing). Will it load then? Run dependency walker (depends.exe) on the DLL and make sure you’ve got all dependencies installed on PATH or in the same directory as the DLL. It’s always useful to run on different VMs to shake out subtle loading differences.
|
|
JNA version 4.2.2. Works fine on 4.1.0. Extracted jnidispatch.dll fails. Where do I get depends.exe? |
|
Found depends.exe with a Google search. The issue is that v4.2.2 cannot find msvcr100.dll. v4.1.0 did not have this problem (on the same host). |
|
Good find. I switched from a winXP build machine to one running Vista. Apparently that is too “new” :)
|
|
My hosts are Windows 7, and Windows Server 2012R2, 2008, and 2008R2 -- same results on all 3. |
Because of compatibility problems, see java-native-access/jna#636
|
I am also seeing this. jnidispatch.dll fails to load with a Shouldn't jnidispatch.dll be statically linked to msvcr100.dll to avoid this runtime dependency?
|
|
@twall I'm not yet to firm in the native build and just managed to get a native build done on windows, but I agree with @guillerodriguez the build now dynamically links against msvcr100.dll. I used my google-foo and came up with this modification to the native Makefile: diff --git a/native/Makefile b/native/Makefile
index 8e30e62..abaf000 100644
--- a/native/Makefile
+++ b/native/Makefile
@@ -219,7 +219,7 @@ endif
ifeq ($(USE_MSVC),true)
# MS compiler
-CC=$(FFI_SRC)/msvcc.sh
+CC=$(FFI_SRC)/msvcc.sh -DUSE_STATIC_RTL
COPT=
CPP=cl -nologo -EP
LD=linkbefore depends.exe repored msvcr100.dll as a dependency. With this modification that dependency is gone. Do you agree? |
|
That makes sense to me. On Wednesday, June 8, 2016, matthiasblaesing notifications@github.com
|
|
It might be better put into CDEFINES or another make variable shared On Thursday, June 9, 2016, Timothy Wall twalljava@java.net wrote:
|
|
Ok - I managed to do a test build of this # This patch file was generated by NetBeans IDE
# It uses platform neutral UTF-8 encoding and \n newlines.
--- a/native/Makefile
+++ b/native/Makefile
@@ -207,19 +207,24 @@
LIBPFX=
LIBSFX=.dll
TESTLIB_TRUNC=$(BUILD)/testlib-truncated.dll
+
ifeq ($(ARCH),amd64)
MINGW_PREFIX?=x86_64-w64-mingw32-
FFI_CONFIG+=--host=x86_64-w64-mingw32
+else
+FFI_CONFIG+=--host=i686-w64-mingw32
+MINGW_PREFIX?=i686-w64-mingw32-
+endif
# Need windres from mingw distribution, even if building with MSVC
WINDRES=$(MINGW_PREFIX)windres
MINGW=$(MINGW_PREFIX)gcc
-else
-MINGW_PREFIX?=i686-pc-mingw32-
-endif
ifeq ($(USE_MSVC),true)
# MS compiler
CC=$(FFI_SRC)/msvcc.sh
+ifneq ($(DYNAMIC_LIBFFI),true)
+CDEFINES+=-DUSE_STATIC_RTL
+endif
COPT=
CPP=cl -nologo -EP
LD=linkI did not push this as a PR, as I did more work than strictly necessary for this bug. To be able to compile with current cygwin I had to adjust the variables for the 32 bit builds (see above). With the changes above I can build: 32bit + 64bit with MSVC + MINGW. Dependencies according to depends.exe:
From my reading these are save assumptions. With regard to the mingw modifications for the build - I installed cygwin from a recent version and used the dependencies:
Is this change ok? |
|
I'm running also in the same error on a Windows 7 32bits machine. |
Without this modification the jnidispatch.dll (when built by MSVC) is dynamicly linked against msvcr100.dll. This requires the corresponding runtime libraries to be installed. Closes: java-native-access#636
Without this modification the jnidispatch.dll (when built by MSVC) is dynamicly linked against msvcr100.dll. This requires the corresponding runtime libraries to be installed. Closes: java-native-access#636
|
I used the tool to figure out the missing dependency, and it was the "liblept1790.dll". I had it but in different minor version. Tess4j 4.5.3 required exactly and specifically lept4j version 1.13.0 |
I'm getting the subject error even though the DLL is created in the temp directory (and then immediately removed, but not sure if it's before or after the error displays):
C:\Users\ADMINI~1\AppData\Local\Temp\1\jna-146731693\jna290172322139546992.dll (JVMPORT015E Unable to resolve shared library references - a prerequisite shared library may be missing)
Exception: java.lang.UnsatisfiedLinkError
at java.lang.ClassLoader.loadLibraryWithPath(ClassLoader.java:1035)
at java.lang.System.load(System.java:495)
at com.sun.jna.Native.loadNativeDispatchLibraryFromClasspath(Native.java:851)
at com.sun.jna.Native.loadNativeDispatchLibrary(Native.java:826)
at com.sun.jna.Native.(Native.java:140)
at java.lang.J9VMInternals.initializeImpl(Native Method)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:201)
at com.sun.jna.Pointer.(Pointer.java:41)
at java.lang.J9VMInternals.initializeImpl(Native Method)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:201)
at com.sun.jna.platform.win32.WinNT$HANDLEByReference.(WinNT.java:1265)
at com.sun.jna.platform.win32.WinNT$HANDLEByReference.(WinNT.java:1261)
at com.sun.jna.platform.win32.Advapi32Util.getCurrentUserGroups(Advapi32Util.java:439)
at com.ford.os.OS.isAdmin(OS.java:99)
at com.ford.wasaids.command.AbstractCommand.checkAdminUser(AbstractCommand.java:209)
at com.ford.wasaids.command.Install.checkAdminUser(Install.java:95)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:611)
at com.ford.wasaids.command.AbstractCommand.process(AbstractCommand.java:504)
at com.ford.wasaids.command.CommandProcessor.perform(CommandProcessor.java:272)
at com.ford.wasaids.command.CommandProcessor.main(CommandProcessor.java:339)
The text was updated successfully, but these errors were encountered: