Thank you! Using lwjgl3 fixes the issue.
does this anyway also mean LWJGL3 package is now more stable than 2 now?
Unclear to me… Could be that the next system update breaks lwjgl3 and fixes lwjgl2…
That’s the risk of being on the bleeding edge sometimes.
This seems like a native library linking issue and could probably happen to any precompiled binary, I guess.
well, we have Centos always up2date, had no problems like this. i dont know much about Arch linux.
I recently tried to work on some of my jME projects with Java 12
Anyway did system updated to Java 12 or it was earlier that version? maybe its just about java 12 dont work with jme-lwjgl package? (because when he changed to jme-lwjgl3 it work)
Except according to OP, Java 12 worked with it at one point and then stopped working.
We actually don’t know what the issue is, I guess. So anything is speculation. That library X works and library Y doesn’t isn’t enough on its own to decide what’s bad or not… given that nothing specific to the library X or Y was updated.
A data-point that may offer some insight:
I’ve just had to troubleshoot a similar error in another app that uses
jogl. I, like the OP, run Arch, but the issue was first reported by an Ubuntu user. (All versions of Java >8 for him)
On Arch, it broke after a Java 12 update. Java 10 is still good, not updated in a while.
I’ve found a few references to similar around the 'net, all related to loading native code modules.
This eclipse bug seems to have the most insight.
If they’re right, it’s going to depend on what version of glibc you jvm is using, and possibly what was present when your native payload was compiled.
Not sure if this helps, but perhaps a point for further investigation.
Still seems like less a “JME problem” than a “Linux getting it’s sh*t together” problem. (Note: not trying to be down on Linux, I’m a fan… but this stuff is kind of what scares people off.)
I’ve been thinking about this for a bit. What is the difference between lwjgl2 & 3, in terms of how the native libraries are structured?
Answering that could give us some meat to throw to the people who maintain our JVM distributions.
LWJGL 2 & 3 are totally different internally. As I recall, LWJGL 2 used its own native code to bind Java <-> platform libs (GL, input, etc). LWJGL 3 uses auto-generated bindings for all of its native code, and it relies on GLFW for support for graphics (OpenGL & Vulkan), input, windowing etc.
Aha! So, it looks like lwjgl 3 is using a monolithic native library, where lwjgl 2 had at least a couple… Jinput has it’s own natives.
Might support the glibc bug hypothesis, as that bug is about loading multiple libraries in parallel…
I believe the “core” LWJGL is using one native library (GLFW), yes - but it is modular, so any of the plethora of extra libraries it provides are loaded from separate native libraries.
Do we have any way of knowing how many native libraries were involved in op’s test?
I think a reasonably close guess could be made based on the dependencies he has, but without knowing for sure we can only guess (is it just the core LWJGL libs, and if so, what natives do they load, is Bullet in the mix, etc).
I’ve just come across this issue myself.
I’ve been developing using 11.0.4 and LWJGL2 and it works. I upgraded to 11.0.5 and I get the error specified in the OP.
05 Jan 2020 10:47:07 [ WARN | javafx ] Loading FXML document with JavaFX API of version 11.0.1 by JavaFX runtime of version 11 05 Jan 2020 10:47:07 [ INFO | JmeSystem ] Running on jMonkeyEngine 3.3-alpha5 * Branch: HEAD * Git Hash: bb32b88 * Build Date: 2019-09-21 Inconsistency detected by ld.so: dl-lookup.c: 111: check_match: Assertion `version->filename == NULL || ! _dl_name_match_p (version->filename, map)' failed!
using LWJGL3 gets rid of this error.
So it appears to be some kind of issue with LWJGL2 and Java 11.0.5 and above, since 11.0.4 works.
That’s what @grizeldi got when trying to launch lwjgl as well!
I was trying to launch the latest version of the sdk, and got the same error, yep.
Interestingly, a recent pre-release version of jogamp fixes the variant that I ran across… Maybe one of those “oh, the API should be compatible… If you recompile against the new library” situations?
Jan. 26, 2020 5:46:49 NACHM. com.jme3.system.JmeDesktopSystem initialize INFORMATION: Running on jMonkeyEngine 3.2-stable * Branch: HEAD * Git Hash: f85624a * Build Date: 2018-01-21 Inconsistency detected by ld.so: dl-lookup.c: 111: check_match: Assertion `version->filename == NULL || ! _dl_name_match_p (version->filename, map)' failed!
I keep getting the same error when trying to start this simple game: jMonkeyEngine | Quick Start
Yes, you either need openJDK 11.0.4 (not 11.0.5) or lwjgl3 instead of lwjgl2 unfortunately.
Yep. You have to use Java 11.0.5 and the lwjgl3 dependency, not the lwjgl dependency.