[FIXED] Urgent panic - JRE7 / LWJGL / Linux broken

[princec]

Full summary here: basically the update to Java 7 is breaking everyones' LWJGL games. Looks like libjawt.so has once again managed to creep into AWT dependency somehow - I seem to recall issues similar to this years ago on Windows. Anybody working on the Linux port here confirm that it's a simple fix (or knows one?)

Cas

[kappa]

Following the above post links to another here http://getsatisfaction.com/mojang/topics/minecraft_doesnt_work_with_java_7

Which states the error with Java 7 is the following:

Code:

home/andrey/.minecraft/bin/natives/liblwjgl.so: wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch)

There is a workaround mentioned in the comments on that post.

There was recently a fix applied to LWJGL which changed the way it loads 32/64bit natives so the nightly builds might already work, can anyone confirm if nightly builds also fail?

[kulpa]

nope, not working.
downloaded fresh archive from Jenkins (jars #1276, liblwjgl.so #1326, liblwjgl64.so #1330)

Code:

$ unset LD_LIBRARY_PATH
$ java -cp libs/lwjgl.jar:libs/lwjgl_test.jar -Djava.library.path=libs/linux/ -Dorg.lwjgl.util.Debug=true org.lwjgl.test.DisplayTest
==== Test Current ====
Info about current:
[LWJGL] Failed to load 64 bit library: /home/kulpae/sandbox/LWJGL/libs/linux/liblwjgl64.so: libjawt.so: cannot open shared object file: No such file or directory
[LWJGL] Failed to load 64 bit library: /home/kulpae/sandbox/LWJGL/libs/linux/liblwjgl64.so: libjawt.so: cannot open shared object file: No such file or directory
Exception in thread "main" java.lang.UnsatisfiedLinkError: no lwjgl in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1860)
at java.lang.Runtime.loadLibrary0(Runtime.java:845)
at java.lang.System.loadLibrary(System.java:1084)
at org.lwjgl.Sys$1.run(Sys.java:73)

now after the fix:

Code:

$ export LD_LIBRARY_PATH="/opt/java/jre/lib/amd64"
$ java -cp libs/lwjgl.jar:libs/lwjgl_test.jar -Djava.library.path=libs/linux/ org.lwjgl.test.DisplayTest
==== Test Current ====
Info about current:
Graphics card: null, version: null
Resolution: 1600x900x24@60Hz
---- Test Current ----
==== Test query ====
Retrieving available displaymodes
Found 6 modes
...

Code:

$ uname -srm
Linux 3.0-ARCH x86_64
java -version
$ java version "1.7.0"
Java(TM) SE Runtime Environment (build 1.7.0-b147)
Java HotSpot(TM) 64-Bit Server VM (build 21.0-b17, mixed mode)

edit: compiled from svn, still the same issue...
edit2: this also works..

Code:

$ unset LD_LIBRARY_PATH
$ sudo ldconfig /opt/java/jre/lib/amd64/

[Matzon]

so, who is the problem exactly ?

[cookiecaper]

There was recently a fix applied to LWJGL which changed the way it loads 32/64bit natives so the nightly builds might already work, can anyone confirm if nightly builds also fail?

As described in the linked thread, there are other issues after working around the ELFCLASS errors, but

Code:

sudo ldconfig /opt/java/jre/lib/amd64

seems to resolve this. There seems to be some confusion over whether this is a packaging problem specific to distros, which would seem to be the case if we simply need to use ldconfig, or if there is a real problem with lwjgl. Diagnosis based on this info?

[kappa]

doing some searching on this problem it seems that there was a similar issue with libjawt.so all the way back in the LWJGL 0.95 days. The fix that was eventually used was calling the following code before the lwjgl natives are loaded:

Code:

static {
java.awt.Toolkit.getDefaultToolkit(); // This will make sure libjawt.so is loaded
}

It could be that Java 7 is somehow changing this behaviour making it a JRE bug.

[kappa]

I posted this problem on one of the java mailing lists and got the following response:

> Hi,

If adding the library on the system library path is fixing it, it could be related to:

6367077: Purge LD_LIBRARY_PATH usage from the launcher
http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/de45eac5670e

'Previously the launcher modified the LD_LIBRARY_PATH appropriately for the
 desired data model path, regardless if data models matched or not. The
 launcher subsequently exec'ed the desired executable, in order to make the
 LD_LIBRARY_PATH path available for the runtime linker. This is no longer the
 case, the launcher dlopens the target libjvm.so. All other required
 libraries are loaded by the runtime linker, by virtue of the $ORIGIN paths
 baked into the shared libraries, by the build infrastructure at compile time.'

Have you only seen this with LWJGL i.e. can other Java applications find libjawt.so?

--
Andrew

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org

So not sure if this will still be considered a JRE bug.

Discussing this further on the LWJGL IRC Channel it was suggested that libjawt.so gets loaded with Toolkit.getDefaultToolkit() (by dlopening), but the linker doesn't see it as it's not in LD_LIBRARY_PATH and this problem might be worked around by using "dlsym(NULL, "JAWT_GetAWT")".

[kappa]

ok here's a temp fix for those that need one urgently. At the start of your program (before any LWJGL calls) run the following snippet of code.

Code:

String osArch = System.getProperty("os.arch");
boolean is64bit = "amd64".equals(osArch) || "x86_64".equals(osArch);

java.awt.Toolkit.getDefaultToolkit(); // loads libmawt.so (needed by jawt)

if (is64bit) System.load(System.getProperty("java.home") + "/lib/amd64/libjawt.so");
else System.load(System.getProperty("java.home") + "/lib/i386/libjawt.so");

This should get your stuff working on Java 7 Linux for now, while a proper fix that can be integrated into LWJGL is investigated.

LWJGL has been relying on java.awt.Toolkit.getDefaultToolkit() to load jawt on linux but its no longer the behaviour of the method with Java 7.

[kappa]

This issue should now be fixed and will be part of the next nightly build. Do test and provide feedback on whether it works.

[kulpa]

confirmed, is working now

[TheRealBecks]

Hello everyone,

I want to start tectonicus, a map generator for minecraft. But I get this error also posted in your thread:

Code:

Forcing 64-bit native libraries
Player skin cache is old or corrupt, cleaning...
Creating player icon assembler
Initialising display...
Exception in thread "main" java.lang.UnsatisfiedLinkError: /home/server/.tectonicus/native/liblwjgl.so: libjawt.so: Kann die Shared-Object-Datei nicht öffnen: Datei oder Verzeichnis nicht gefunden
        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1924)
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1821)
        at java.lang.Runtime.load0(Runtime.java:792)
        at java.lang.System.load(System.java:1059)
        at org.lwjgl.Sys$1.run(Sys.java:70)
        at java.security.AccessController.doPrivileged(Native Method)
        at org.lwjgl.Sys.doLoadLibrary(Sys.java:66)
        at org.lwjgl.Sys.loadLibrary(Sys.java:82)
        at org.lwjgl.Sys.<clinit>(Sys.java:99)
        at org.lwjgl.opengl.Display.<clinit>(Display.java:130)
        at tectonicus.rasteriser.lwjgl.LwjglRasteriser.<init>(LwjglRasteriser.java:110)
        at tectonicus.rasteriser.RasteriserFactory.createRasteriser(RasteriserFactory.java:24)
        at tectonicus.TileRenderer.<init>(TileRenderer.java:146)
        at tectonicus.TectonicusApp.run(TectonicusApp.java:808)
        at tectonicus.TectonicusApp.main(TectonicusApp.java:1173)

(--> can't open shared object file: No such file or directory)

So I copied liblwjgl.so, liblwjgl64.so and liblwjgl.jar (all nightly builds) to Tectonicus and started again - no change in result. I use Ubuntu 11.10 beta 2 (headless, no X-server) with openjdk-7-jre.

Has anyone an idea, what I have to do?

[kappa]

You must still be using the old lwjgl.jar. That is the is the most important file to replace for the fix, do double check that it is indeed using the nightly version of this jar.

[TheRealBecks]

Ok, your sentence is not so easy to translate into german, but what I understand is: I have to check, if Tectonicus is using the nightly version of lwjgl.jar, right?

[TheRealBecks]

I backupped the files in /usr/shared/java and copied the new version of the files in. Also the new files are in the Tectonicus- and Minecraft-folders, but ist's still the same error. What's wrong?

[TheRealBecks]

To show which files I updated, I executed a find-command:

Code:

server@kastenbier:~$ sudo find / -name "*lwjgl*"
/home/server/.tectonicus/native/lwjgl.dll
/home/server/.tectonicus/native/liblwjgl.so
/home/server/.tectonicus/native/lwjgl64.dll
/home/server/.tectonicus/native/liblwjgl64.so
/home/server/.tectonicus/native/liblwjgl.jnilib
/home/server/.minecraft/bin/lwjgl.jar.bak
/home/server/.minecraft/bin/natives/liblwjgl.so
/home/server/.minecraft/bin/natives/liblwjgl64.so
/home/server/.minecraft/bin/lwjgl.jar
/home/server/.minecraft/bin/lwjgl_util.jar
/home/server/lwjgl
/home/server/lwjgl/liblwjgl.so
/home/server/lwjgl/lwjgl.jar
/home/server/lwjgl/lwjgl_util.jar
/home/server/lwjgl/lwjgl_test.jar
/home/server/lwjgl/liblwjgl64.so
/home/server/lwjgl/lwjgl_util_applet.jar
/home/server/lwjgl/lwjgl-debug.jar
/var/lib/dpkg/info/liblwjgl-java-jni.md5sums
/var/lib/dpkg/info/liblwjgl-java-jni.list
/var/lib/dpkg/info/liblwjgl-java.md5sums
/var/lib/dpkg/info/liblwjgl-java.list
/var/cache/apt/archives/liblwjgl-java-jni_2.7.1+dfsg-1_amd64.deb
/var/cache/apt/archives/liblwjgl-java_2.7.1+dfsg-1_all.deb
/usr/share/doc/liblwjgl-java-jni
/usr/share/doc/liblwjgl-java
/usr/share/java/lwjgl_util.jar
/usr/share/java/lwjgl_util.jar.bak
/usr/share/java/lwjgl.jar
/usr/share/java/lwjgl.jar.bak
/usr/share/java/lwjgl_test.jar
/usr/share/java/lwjgl_test.jar.bak
/usr/share/java/lwjgl_util_applet.jar
/usr/share/java/lwjgl_util_applet.jar.bak
/usr/lib/jni/liblwjgl.so.bak
/usr/lib/jni/liblwjgl.so

Also .tetonicus and .minecraft got the new files, but without backupping the old ones.