Issues using JPL on Windows and JDK > 8

seiferma commented 4 years ago

I am having a pretty hard time to get JPL running under Windows. I am using SWI Prolog 8.0.3 and JPL 7.4.0. I tried various JVMs but only managed to get running it using Java 8 (AdoptOpenJDK Hotspot). The following JVMs failed:

AdoptOpenJDK 11, Hotspot
AdoptOpenJDK 11, OpenJ9
OracleJDK 13, Hotspot

The error is always more or less the same:

Current thread (0x0000029c55ed2800):  JavaThread "main" [_thread_in_native, id=18052, stack(0x000000e740d00000,0x000000e740e00000)]

Stack: [0x000000e740d00000,0x000000e740e00000],  sp=0x000000e740dfde60,  free space=1015k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libswipl.dll+0x2b10]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  org.jpl7.fli.Prolog.open_query(Lorg/jpl7/fli/module_t;ILorg/jpl7/fli/predicate_t;Lorg/jpl7/fli/term_t;)Lorg/jpl7/fli/qid_t;+0
j  org.jpl7.Query.open()V+238
j  org.jpl7.Util.textToTerm(Ljava/lang/String;)Lorg/jpl7/Term;+57
j  org.jpl7.Query.<init>(Ljava/lang/String;)V+2
j  swiprolog.MultiThreadTest.insert(Ljava/lang/String;Ljava/lang/String;)V+39
j  swiprolog.MultiThreadTest.testSimpleQueries(I)V+26
j  swiprolog.MultiThreadTest.singleThreadTest()V+12
v  ~StubRoutines::call_stub
j  jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Ljava/lang/reflect/Method;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0 java.base@13.0.1
j  jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+100 java.base@13.0.1
j  jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+6 java.base@13.0.1
j  java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+59 java.base@13.0.1
j  org.junit.runners.model.FrameworkMethod$1.runReflectiveCall()Ljava/lang/Object;+15
j  org.junit.internal.runners.model.ReflectiveCallable.run()Ljava/lang/Object;+1
j  org.junit.runners.model.FrameworkMethod.invokeExplosively(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+10
j  org.junit.internal.runners.statements.InvokeMethod.evaluate()V+12
j  org.junit.runners.ParentRunner.runLeaf(Lorg/junit/runners/model/Statement;Lorg/junit/runner/Description;Lorg/junit/runner/notification/RunNotifier;)V+17
j  org.junit.runners.BlockJUnit4ClassRunner.runChild(Lorg/junit/runners/model/FrameworkMethod;Lorg/junit/runner/notification/RunNotifier;)V+30
j  org.junit.runners.BlockJUnit4ClassRunner.runChild(Ljava/lang/Object;Lorg/junit/runner/notification/RunNotifier;)V+6
j  org.junit.runners.ParentRunner$3.run()V+12
j  org.junit.runners.ParentRunner$1.schedule(Ljava/lang/Runnable;)V+1
j  org.junit.runners.ParentRunner.runChildren(Lorg/junit/runner/notification/RunNotifier;)V+44
j  org.junit.runners.ParentRunner.access$000(Lorg/junit/runners/ParentRunner;Lorg/junit/runner/notification/RunNotifier;)V+2
j  org.junit.runners.ParentRunner$2.evaluate()V+8
j  org.junit.runners.ParentRunner.run(Lorg/junit/runner/notification/RunNotifier;)V+20
j  org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(Lorg/eclipse/jdt/internal/junit/runner/TestExecution;)V+72
j  org.eclipse.jdt.internal.junit.runner.TestExecution.run([Lorg/eclipse/jdt/internal/junit/runner/ITestReference;)V+17
j  org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests([Ljava/lang/String;Ljava/lang/String;Lorg/eclipse/jdt/internal/junit/runner/TestExecution;)V+62
j  org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(Lorg/eclipse/jdt/internal/junit/runner/TestExecution;)V+10
j  org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run()V+70
j  org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main([Ljava/lang/String;)V+14
v  ~StubRoutines::call_stub

siginfo: EXCEPTION_ACCESS_VIOLATION (0xc0000005), reading address 0x000000007b4ca140

I first throught that I am initialzing JPL in a wrong way or formulated an invalid Query but the exactly same code runs perfectly fine on the mentioned JDK 8 or on Linux. Anyway, I assume that Java 11 is supported in general because of the statements on the official website.

Unfortunately, I could not find much information about such issues except of one reported issue: ssardina-research/packages-jpl#23. The solution for that issue was downgrading to Java 8. However, this is not an option for me because I have to integrate my code into a larger project that requires Java 11.

I would be very grateful for any information on tracking down or solving the issue. Of course, I am keen to provide more information.

nomisto commented 4 years ago

Got the same error: hs_err_pid8412.log

JanWielemaker commented 4 years ago

Although I doubt it makes a difference, did you try the current development branch?

The Windows build for JPL is quite problematic. SWI-Prolog for Windows is cross-compiled from Linux, but getting recent versions of the Oracle JDK installed in Wine was pretty much impossible the last time I tried.

Since the move to CMake it is feasible to build the system on native Windows AFAIK, which may allow building against a more recent JDK and, if needed, look around using a debugger.

seiferma commented 4 years ago

Sorry for my delayed response. I was on vacation.

Is there any ready to use binary that I can give a try or should I build it by myself?

JanWielemaker commented 4 years ago

Not that I'm aware of. This requires a Windows developer, probably with some Java knowledge. Sorry.

ssardina commented 4 years ago

@seiferma, the statements in the site you refer actually suggest that beyond SE 8 you will most probably have problems. What am I missing here?

I remember trying OpenJDK 11 and failing to make it work, but haven't dig into it too much; should look at it again.

BTW, at one point you said: "but the exactly same code runs perfectly fine on the mentioned JDK 8 or on Linux". Does this mean it work in Linux with Java 11+ (but does not run in Windows though)? That would be surprising as I am pretty sure it did not work for me with Java 11 in Linux.

Also, see that version 8.0.3 may have issues as the CMAKE had a little bug. This was fixed in the development version (in git repo) and will be seen in version 8.1.x. So you may want to compile 8.1.x from scratch or go down to 7.6.x? check this post

JanWielemaker commented 4 years ago

My development machine runs Ubuntu 19.04 using openjdk 13 2019-09-17. That builds JPL fine and it passes the tests. This is using the development version of SWI-Prolog, but I'd do that anyway as it is rock stable at the moment. Current development is tabling. In other areas there are just bug fixes and very few new things. Tabling in the development version is a lot better, but does sometimes suffer from regression.

seiferma commented 4 years ago

@ssardina: As @JanWielemaker already said, even recent Java versions work fine on Ubuntu (which I used to test it). Most probably, this holds true for other distributions as well.

I tried to compile SWI-Prolog natively with the VS Build Tools but did not get very far because of missing dependencies. I am not completely sure if the build definition is really made to be build natively without mingw. I might also have missed something because there is no complete manual on building natively without mingw (or at least I could not find it).

I also gave the development builds a try. The latest builds do not work because JPL::init reports that it cannot find important ressources. I suspect the boot.prc file to be the problem because previously, the file was called boot64.prc or boot32.prc. Anyway, I am not sure about this.

After going back to 8.1.0-1, the error disappears (boot64.prc is there) but the same exception as initially reported is thrown.

javatlacati commented 4 years ago

I've been looking into the maven branch, I think I'll try to make it even with the other branches so builds can be repeatable and we can test them out with Travis CI and or Appveyor.

However the reported problem is not in JPL but on swipl itself, according to the trace it is in

libswipl.dll

Got similar errors building on JDK 13 and 11. I've recently installed JDK 8 in order to see if it's a compatibility problem with the JVM version.

javatlacati commented 4 years ago

Same problem trying to build with Adopt OpenJDK 8:

[INFO] --- maven-surefire-plugin:2.19.1:test (default-test) @ packages-jpl ---

-------------------------------------------------------
 T E S T S
-------------------------------------------------------
Running org.jpl7.test.JPLTest
#
[thread 18868 also had an error]# A fatal error has been detected by the Java Runtime Environment:
[thread 15424 also had an error]#
#  EXCEPTION_ACCESS_VIOLATION[thread 19280 also had an error] (0xc0000005) at pc=0x0000000069d42b10
, pid=17540
, tid=0x00000000000043b4
#
# JRE version: OpenJDK Runtime Environment (8.0_242-b08) (build 1.8.0_242-b08)
# Java VM: OpenJDK 64-Bit Server VM (25.242-b08 mixed mode windows-amd64 compressed oops)
# Problematic frame:
# C  [libswipl.dll+0x2b10]
#
# Failed to write core dump. Minidumps are not enabled by default on client versions of Windows
#
# An error report file with more information is saved as:
# C:\Users\RuslanLopez\IdeaProjects\packages-jpl\hs_err_pid17540.log
#
# If you would like to submit a bug report, please visit:
#   
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

hs_err_pid17540.log

JanWielemaker commented 4 years ago

This issue has been mentioned on SWI-Prolog. There might be relevant details there:

https://swi-prolog.discourse.group/t/ann-swi-prolog-8-1-24/1958/1

ssardina commented 4 years ago

Hi @javatlacati

I am a bit lost. Are you running on Linux or Windows?

I compiled and run the test with OpenJDK 11 and it was all good:

[ssardina@Thinkpad-X1 build-openjdk]$ !ctes
ctest -R jpl:prolog_in_java ; ctest -R jpl:java_in_prolog
Test project /home/ssardina/git/soft/prolog/swipl-devel.git/build-openjdk
    Start 62: jpl:prolog_in_java
1/1 Test #62: jpl:prolog_in_java ...............   Passed    1.18 sec

100% tests passed, 0 tests failed out of 1

Total Test time (real) =   1.19 sec
Test project /home/ssardina/git/soft/prolog/swipl-devel.git/build-openjdk
    Start 63: jpl:java_in_prolog
1/1 Test #63: jpl:java_in_prolog ...............   Passed    0.60 sec

100% tests passed, 0 tests failed out of 1
Total Test time (real) =   0.61 sec

[ssardina@Thinkpad-X1 build-openjdk]$ javac -version
javac 11.0.7
[ssardina@Thinkpad-X1 build-openjdk]$ java -version
openjdk version "11.0.7" 2020-04-14
OpenJDK Runtime Environment (build 11.0.7+10-post-Ubuntu-2ubuntu218.04)
OpenJDK 64-Bit Server VM (build 11.0.7+10-post-Ubuntu-2ubuntu218.04, mixed mode, sharing)

Could this be an issue with Maven? I can try that. See the maven branch was a bit of a shortcut. The idea is to get a pom.xml in the root of the master branch and that's it.

Are you modifying the JAVA API?

ssardina commented 4 years ago

Hi @seiferma

yes, I have OpenJDK 11 in Linux Mint and works well and can compile latest SWIPL and JPL.

Windows, I have no idea. I started trying in a Virtualbox but then realized I know very little about Windows and have little time and motivation to learn about it; it is not trivial to set-up the whole environment to compile SWIPL...

ssardina commented 4 years ago

Hi @javatlacati . Can you check if the latest version works for you? Lots of things have been fixed.

Venorcis commented 4 years ago

Just to summarise my contributions from #82, any Oracle Java version beyond 8u251 causes access violations with JPL on Windows. This seems to be because of their move from VS 2010 SP1 to VS 2017, see https://www.oracle.com/java/technologies/javase/8u261-relnotes.html

JanWielemaker commented 4 years ago

Just for the sake of it, I tried adding -l msvcr100 to the MinGW build. This does indeed produce a binary that requires msvcr100.dll. It still also seems to link to msvcrt.dll though. Not sure that is a problem or not. In any case, the result crashes the same way. Might be the wrong trail :cry:

Venorcis commented 4 years ago

Just for the sake of it, I tried adding -l msvcr100 to the MinGW build. This does indeed produce a binary that requires msvcr100.dll. It still also seems to link to msvcrt.dll though. Not sure that is a problem or not. In any case, the result crashes the same way. Might be the wrong trail 😢

Well I guess that the Oracle release note explicitly states that at least VS 2017 must now be used for native libraries? These applications should be rebuilt and shipped with modern C++ runtime dependencies that use a later instance of Visual Studio. Applications should not depend on DLLs included with the JDK/JRE that are not documented in the product as offering support for the specification or other functionality in Java SE.

JanWielemaker commented 4 years ago

@ssardina says

I compiled and run the test with OpenJDK 11 and it was all good:

This is quite interesting as https://hi.service-now.com/kb_view.do?sysparm_article=KB0853593 also says

Workaround

If customer desires the security updates from newer versions of java, upgrade your JVM to use Java 11. It is important to note that this option will disable MID CPU monitoring unctionality on Windows.

Downgrade your JVM to 8.0_251, or switch to using the bundled 1.8.0_231

@Venorcis quotes

modern C++ runtime dependencies

This may be relevant, but note that there is no C++ in SWI-Prolog or JPL. All is plain C, which is typically better interoperable.

Venorcis commented 4 years ago

I've just tried it with the latest OpenJDK 14 installed. Same access violation errors I'm afraid... I see others here reporting issues with various other versions too. @ssardina response was based on testing on Ubuntu; this issue is probably specific to Windows ;)

Relevant part of the trace:

Current thread (0x000001e4c8e4f000):  JavaThread "main" [_thread_in_native, id=9588, stack(0x000000494e100000,0x000000494e200000)]

Stack: [0x000000494e100000,0x000000494e200000],  sp=0x000000494e1fda50,  free space=1014k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libswipl.dll+0x41575]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  org.jpl7.fli.Prolog.open_query(Lorg/jpl7/fli/module_t;ILorg/jpl7/fli/predicate_t;Lorg/jpl7/fli/term_t;)Lorg/jpl7/fli/qid_t;+0
j  org.jpl7.Query.open()V+237
j  org.jpl7.Term.textToTerm(Ljava/lang/String;)Lorg/jpl7/Term;+57
j  org.jpl7.Query.<init>(Ljava/lang/String;)V+2

siginfo: EXCEPTION_ACCESS_VIOLATION (0xc0000005), reading address 0xffffffffefd656c0

There are also some hints to the 'procedure could not be found' errors, similar to #82:

Internal exceptions (8 events):
Event: 0.621 Thread 0x000001e4c8e4f000 Exception <a 'java/lang/IncompatibleClassChangeError'{0x00000007134d7f60}: Found class java.lang.Object, but interface was expected> (0x00000007134d7f60) 
thrown [./src/hotspot/share/interpreter/linkResolver.cpp, line 832]
Event: 0.662 Thread 0x000001e4c8e4f000 Exception <a 'java/lang/NoSuchMethodError'{0x000000071320d878}: 'int java.lang.invoke.DirectMethodHandle$Holder.invokeSpecialIFC(java.lang.Object, java.lang.Object, int)'> (0x000000071320d878) 
thrown [./src/hotspot/share/interpreter/linkResolver.cpp, line 766]
Event: 0.813 Thread 0x000001e4c8e4f000 Exception <a 'java/lang/NoSuchMethodError'{0x0000000712b0bf40}: 'java.lang.Object java.lang.invoke.DirectMethodHandle$Holder.invokeStaticInit(java.lang.Object, int, int, int, int)'> (0x0000000712b0bf40) 
thrown [./src/hotspot/share/interpreter/linkResolver.cpp, line 766]
Event: 0.865 Thread 0x000001e4c8e4f000 Exception <a 'java/lang/NoSuchMethodError'{0x0000000712b266f0}: 'java.lang.Object java.lang.invoke.DirectMethodHandle$Holder.invokeStaticInit(java.lang.Object, java.lang.Object, int, int, int, int)'> (0x0000000712b266f0) 
thrown [./src/hotspot/share/interpreter/linkResolver.cpp, line 766]
Event: 0.934 Thread 0x000001e4c8e4f000 Implicit null exception at 0x000001e4d93d4ba5 to 0x000001e4d93d536c
Event: 0.950 Thread 0x000001e4c8e4f000 Exception <a 'java/lang/UnsatisfiedLinkError'{0x000000071285ddb8}: The specified procedure could not be found.

> (0x000000071285ddb8) 
thrown [./src/hotspot/share/prims/jni.cpp, line 620]
Event: 0.975 Thread 0x000001e4c8e4f000 Implicit null exception at 0x000001e4d93d6625 to 0x000001e4d93d6db0
Event: 0.984 Thread 0x000001e4c8e4f000 Exception <a 'java/lang/UnsatisfiedLinkError'{0x0000000713c7fc70}: The specified procedure could not be found.

> (0x0000000713c7fc70) 
thrown [./src/hotspot/share/prims/jni.cpp, line 620]

JDK 14 seems to load a bundled VCRUNTIME140.dll and msvcp140.dll, but also the system msvcrt.dll and msvcp_win.dll.

JanWielemaker commented 4 years ago

I did quite a few tests. Indeed, OpenJDK11 on Windows fails the same way :( Other observations

If I compile SWI-Prolog in debug mode OpenJDK no longer finds the JNI functions from jpl.dll :(
If I try to run OpenJDK Java under gdb (8) it crashes way before reaching Prolog, reporting a corrupted stack :(
If I enable C level debug messages in the release version I can indeed get messages on progress. Turns out the whole Prolog initialization works fine. This (to me) suggests that library interoperability is not the most likely issue.
Trying to call more of the JNI functions it crashes in Prolog (as reported by Java). Trying to attach gdb using -XX:OnError="gdb - %p" works, but when the access violation is trapped the stack is reported corrupt, and even the top frame which is supposed to be in Prolog is broken.

This starts to suggest that modern Java uses different calling conventions. Browsing I saw some hint in this direction, but I have not found any conclusive answers. Also the fact that one can embed Java in Prolog seems to contradict this.

These days, thanks to CMake, it is possible to compile the core of SWI-Prolog using MSVC. I guess with some persistence it is also possible to compile extensions such as JPL. In previous experience MSVC does a lot worse job though (producing a significantly slower version) and getting all dependencies compiled using MSVC to get a fully functional SWI-Prolog is a lot of work. So, I still hope there is a better route.

Venorcis commented 4 years ago

I wish I could help, but I'm not at all at home in this stuff. I tried Googling some parts of the stack trace, and found two or three similar issues, but they were all unresolved 😓 It would be a real shame if we cannot upgrade beyond Java 8u251 on Windows, as this version is 'archived' and might have security issues and such already.

JanWielemaker commented 4 years ago

We see each other tomorrow. Let us brainstorm a little then ...

Venorcis commented 4 years ago

These days, thanks to CMake, it is possible to compile the core of SWI-Prolog using MSVC. I guess with some persistence it is also possible to compile extensions such as JPL. In previous experience MSVC does a lot worse job though (producing a significantly slower version) and getting all dependencies compiled using MSVC to get a fully functional SWI-Prolog is a lot of work. So, I still hope there is a better route.

My OpenJDK 14 is built with MS VC++ 15.9 (VS2017), but this page (and others) suggests using MinGW for JNI is just fine (JDK 10 is given as an example): https://www3.ntu.edu.sg/home/ehchua/programming/java/JavaNativeInterface.html#zz-2.1 Also the error itself (EXCEPTION_ACCESS_VIOLATION) seems to suggest the C code is trying to read some address that doesn't exist or is not accessible (0xffffffffada309d0 for example), so I don't know if this can even be related to the compilation.

I ran with -Xcheck:jni enabled, and the only perhaps useful warning from that output is: WARNING in native method: JNI call made without checking exceptions when required to from CallStaticObjectMethod. It's still just a warning though...

There are also a lot of WARNINNG: JNI local refs: 33, exceeds capacity: 32 or similar (all in increments of 32), but some Googling seems to suggest these aren't fatal issues, although they could be resolved with calling EnsureLocalCapacity properly.

I've also tried the verbose:jni option but this just confirms the error happens when calling org.jpl7.fli.Prolog.open_query. Many other calls before that point work just fine:

[0.363s][debug][jni,resolve] [Dynamic-linking native method org.jpl7.fli.Prolog.set_default_init_args ... JNI]
[0.366s][debug][jni,resolve] [Dynamic-linking native method org.jpl7.fli.Prolog.initialise ... JNI]
[0.377s][debug][jni,resolve] [Dynamic-linking native method org.jpl7.fli.Prolog.thread_self ... JNI]
[0.377s][debug][jni,resolve] [Dynamic-linking native method org.jpl7.fli.Prolog.current_engine ... JNI]
[0.377s][debug][jni,resolve] [Dynamic-linking native method org.jpl7.fli.Prolog.predicate ... JNI]
[0.377s][debug][jni,resolve] [Dynamic-linking native method org.jpl7.fli.Prolog.open_foreign_frame ... JNI]
[0.377s][debug][jni,resolve] [Dynamic-linking native method org.jpl7.fli.Prolog.new_term_refs ... JNI]
[0.377s][debug][jni,resolve] [Dynamic-linking native method org.jpl7.fli.Prolog.put_atom_chars ... JNI]
[0.378s][debug][jni,resolve] [Dynamic-linking native method org.jpl7.fli.Prolog.put_variable ... JNI]
[0.378s][debug][jni,resolve] [Dynamic-linking native method org.jpl7.fli.Prolog.new_atom ... JNI]
[0.378s][debug][jni,resolve] [Dynamic-linking native method org.jpl7.fli.Prolog.new_module ... JNI]
[0.378s][debug][jni,resolve] [Dynamic-linking native method org.jpl7.fli.Prolog.open_query ... JNI]

@JanWielemaker in the Prolog DEBUG mode, do you get some messages on the progress of open_query? There seem to be quite some print statements in there.

Venorcis commented 4 years ago

Just for the heck of it, I tried running with the 32-bits OpenJDK 14. Then I get a completely different error:

java.lang.UnsatisfiedLinkError: 'boolean org.jpl7.fli.Prolog.set_default_init_args(java.lang.String[])'

Seems like the 32-bit Windows jpl.dll isn't fully correctly yet (got it from the 2020-09-15 daily build). Something for later I guess though ;)

Venorcis commented 4 years ago

@JanWielemaker the VU mail blocked my JAR file even in the ZIP ;)

WinDbg Preview: https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-download-tools

Launch executable (advanced): C:\Program Files\AdoptOpenJDK\jdk-14.0.2.12-hotspot\bin\java.exe -jar "C:\Users\Vince\Git\GOAL\krtools\krLanguages\swiprologlibs\target\swiPrologEnabler-1.3.3-SNAPSHOT-shaded.jar"

swiPrologEnabler.zip

JanWielemaker commented 4 years ago

Getting a little further. If I print the values passed to PL_open_query(), I get

PL_open_query(FFFFFFFFCF949E60, 8, FFFFFFFFD00E5C60, 24)

Here, the first and third arguments are pointers to a module and predicate. When I ask the C API for the module pointer, I get 000001EACF949E60, so it seems something is ignoring the upper 32-bit of the pointer and filling it with 0xffffffff (more or less at random, sometimes you get 0x0). This feels like something that should be tractable.

JanWielemaker commented 4 years ago

Pushed bcbc3fb2db6851788fd339c74b4d0a340deebdd9. When a pointer was placed in a PointerHolder, it as casted to long, being 32-bits on Windows. Changed to jlong, being 64 bits. My tests on Windows 10 (64 bits) now pass using OpenJDK 11.

Should be in tomorrows daily build.

Venorcis commented 4 years ago

Pushed bcbc3fb. When a pointer was placed in a PointerHolder, it as casted to long, being 32-bits on Windows. Changed to jlong, being 64 bits. My tests on Windows 10 (64 bits) now pass using OpenJDK 11.

Should be in tomorrows daily build.

Awesome! Will test it tomorrow 👍🏻

Venorcis commented 3 years ago

Can confirm it works now (on 64-bit OpenJDK 14 at least) 😁

JanWielemaker commented 3 years ago

Thanks for testing. I'm closing this issue. I'm not claiming JPL is now perfect on Windows for all JDK versions, but the fundamental reason that caused this issue report seems fixed. Possible other issues should open a new issue here.

JanWielemaker commented 3 years ago

Just for the heck of it, I tried running with the 32-bits OpenJDK 14. Then I get a completely different error:

I think I found it! I've checked out 7.6.0 and tried to build it the old way. Somehow that also fails, but differently. Then I tried some bi-sectioning of the jpl.dll link command and found that the key is -Wl,--kill-at, which was present in the old link line, but not in the new. If I link libjpl by hand in 8.3.7 using -Wl,--kill-at it works fine :smiley:

Now I only have to figure out how to get that integrated into the CMake specs and under which conditions. That is for tomorrow.

JanWielemaker commented 3 years ago

Pushed d89aaae2104d0339d9e3929e9d2ce08cd99a528f, which adds -Wl,--kill-at. This seems required for win32 and doesn't seem to harm win64, so it is now also used for win64. Fingers crossed.

SWI-Prolog / packages-jpl

Issues using JPL on Windows and JDK > 8 #34