FPSDEMO-jMonkeyEngine
FPSDEMO-jMonkeyEngine copied to clipboard
Inconsistency detected by ld.so
I'm able to build, but when I try to run, I get an error from ld.so:
sgold:~/Git/ext/FPSDEMO-jMonkeyEngine$ gradle clean build
BUILD SUCCESSFUL in 21s
4 actionable tasks: 4 executed
sgold:~/Git/ext/FPSDEMO-jMonkeyEngine$ java -jar fps-demo-*.jar
Error: Unable to access jarfile fps-demo-*.jar
sgold:~/Git/ext/FPSDEMO-jMonkeyEngine$ cd build/libs
sgold:~/Git/ext/FPSDEMO-jMonkeyEngine/build/libs$ !j
java -jar fps-demo-*.jar
Oct 16, 2020 1:07:18 PM com.jme3.system.JmeDesktopSystem initialize
INFO: Running on jMonkeyEngine 3.3.2-stable
* Branch: HEAD
* Git Hash: 1a05e3f
* Build Date: 2020-04-27
Inconsistency detected by ld.so: dl-lookup.c: 111: check_match: Assertion `version->filename == NULL || ! _dl_name_match_p (version->filename, map)' failed!
sgold:~/Git/ext/FPSDEMO-jMonkeyEngine/build/libs$ uname -a
Linux sgold-h8-1210t 5.4.0-51-generic #56-Ubuntu SMP Mon Oct 5 14:28:49 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
sgold:~/Git/ext/FPSDEMO-jMonkeyEngine/build/libs$ java -version
openjdk version "14.0.1" 2020-04-14
OpenJDK Runtime Environment (build 14.0.1+7-Ubuntu-1ubuntu1)
OpenJDK 64-Bit Server VM (build 14.0.1+7-Ubuntu-1ubuntu1, mixed mode, sharing)
sgold:~/Git/ext/FPSDEMO-jMonkeyEngine/build/libs$ gradle -v
------------------------------------------------------------
Gradle 4.4.1
------------------------------------------------------------
Build time: 2012-12-21 00:00:00 UTC
Revision: none
Groovy: 2.4.17
Ant: Apache Ant(TM) version 1.10.7 compiled on October 24 2019
JVM: 1.8.0_265 (Private Build 25.265-b01)
OS: Linux 5.4.0-51-generic amd64
sgold:~/Git/ext/FPSDEMO-jMonkeyEngine/build/libs$
I also tried downloading the 1.0 JAR file and got a similar error:
sgold:~/Downloads$ java -jar fps-demo-1.0.0.jar
Oct 16, 2020 1:15:47 PM com.jme3.system.JmeDesktopSystem initialize
INFO: Running on jMonkeyEngine 3.3.2-stable
* Branch: HEAD
* Git Hash: 1a05e3f
* Build Date: 2020-04-27
Inconsistency detected by ld.so: dl-lookup.c: 111: check_match: Assertion `version->filename == NULL || ! _dl_name_match_p (version->filename, map)' failed!
sgold:~/Downloads$
At the Forum, @tonihele wrote:
Ain’t that the LWJGL 2 (Linux specific?) bug thing? Related to java version also…?
I am on Linux. I saw the issue originally with the provided "build.gradle" script, which uses LWJGL 3. I did a clean rebuild using LWJGL2 and observed the same issue.
My Java version is "14.0.2" in case that matters.
I changed my Java version to "1.8.0_272" and that seemed to work around the issue. Now I'm able to play the game.
There were similar issues reported on the forum in the past. You can search Inconsistency detected by ld.so: dl-lookup.c: 111: check_match on the forum for more info.
Seems to be OpenJDK 11+ issue with LWJGL2!
I am on Linux and using AdoptOpenJDK 14 and do not have that issue.
Apparently it also happens with LWJGL3.
Confirmed on Arch, using several different Java versions.
The "Official" OpenJDK builds all seem to have this problem after 1.8.??? ish, while the AdoptOpenJDK builds are fine.
This seems (From previous similar issues, some using jogamp's JOGL library) to be related to an incompatibility in some of the C libraries, perhaps related to exactly what version of glibc is compiled into the JVM?
A libc incompatibility seems plausible to me.
Are we sure this is related to lwjgl and not to the other native libraries?
Given this previous report
- Test app worked through java 11.0.4 with LWJGL2
- Test app worked with LWGJL3 in 11.0.5, but not with LWJGL2
- Consistently reproducible (Not dependent on loading order?)
I'd be very surprised if it was in any other component.
On reflection, I'm finding another little tidbit intriguing here:
When I was looking for help on another project's version of this, I found that the error message about inconsistency seems to only have come up in the context of:
- OpenGL bindings, either LWJGL or Jogamp/JOGL.
- Linux based operating systems. (I was looking for Windows variants w/different library suffixes. None found.)
Not sure whether this implies that there is something specific about video card access on Linux, or if various 3d communities are the only Desktop Java users left that care about performant access to native APIs.