Full summary here (https://bugs.archlinux.org/task/25305): 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 :)
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:
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 (http://lwjgl.org/forum/index.php/topic,3585.0.html) 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?
nope, not working.
downloaded fresh archive from Jenkins (jars #1276, liblwjgl.so #1326, liblwjgl64.so #1330)
$ 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:
$ 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
...
$ 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..
$ unset LD_LIBRARY_PATH
$ sudo ldconfig /opt/java/jre/lib/amd64/
so, who is the problem exactly ?
Quote from: kappa on July 29, 2011, 15:50:04
There was recently a fix (http://lwjgl.org/forum/index.php/topic,3585.0.html) 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
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?
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 (http://lwjgl.org/forum/index.php/topic,915.msg6458.html#msg6458). The fix that was eventually used was calling the following code before the lwjgl natives are loaded:
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.
I posted this problem on one of the java mailing lists and got the following response:
Quote> 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")".
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.
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.
This issue should now be fixed and will be part of the next nightly build. Do test and provide feedback on whether it works.
confirmed, is working now
Hello everyone,
I want to start tectonicus, a map generator for minecraft. But I get this error also posted in your thread:
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?
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.
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?
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?
To show which files I updated, I executed a find-command:
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.
Quote from: TheRealBecks on October 07, 2011, 18:23:48
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?
Please go here: http://www.lwjgl.org/download.php (http://www.lwjgl.org/download.php)
And use 2nd link that says "Nightly builds".
Click LWJGL and get lwjgl-2.8.0.zip. Use the files in the "jars" folder and "native" folder.
Hope this helps.
Yes, and that's the problem, because I did. And every file you can see in my last post with the find-command lists the files I replaced. So I really don't know, why this bug anyhow exists.
Ok, another try! Now I edited Tectonicus.*.jar and replaced the files in the "native" folder, so the actual files of lwjgl are stored in. The bug, that he can't find libjawt.so, still exists. libjawt.so in stored in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/libjawt.so, but in /usr/lib/ is the file missing, so I linked it to the one in java-7-openjdk. Now there's another bug known from Ubuntu 11.04 with openjdk-6-jre:
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: /usr/lib/libjawt.so: symbol awt_Unlock, version SUNWprivate_1.1 not defined in file libmawt.so with link time reference
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)
It's the awt_Unlock-bug... -.- That's so depressingly...
You could try the Oracle JRE 6, just download it from the Oracle site.
I downloaded the actual jre 7 from oracle and installed it like is in this posting http://askubuntu.com/questions/32124/how-do-i-install-java-7-from-the-official-tarballs shown -->
Quotetar xvfz jdk-7-linux-x64.tar.gz
sudo update-alternatives --install /usr/bin/java java /[whereever]/jdk1.7.0/bin/java 0
sudo update-alternatives --config java
Installation worked, so I can use this version. But the awt-bug is the same. And jre 6 isn't better than jre 7, because other postings in the internet say, that jre 7 is the answer of the problem and because of this I upgraded Ubuntu 11.04 to 11.11 with official support for jre 7! :D Is there maybe a problem, because no x-server is available?
Please check the wiki: http://www.minecraftwiki.net/wiki/Programs_and_Editors/Tectonicus/VPS
I found this website two weeks ago, too. But it can't be, that noone out there knows, why it's not running? And after two wooks of work I have been forwarded two java and now to lwjgl. And in this topic the bug I have is posted. So hell, what is it, if lwjgl is working correctly? :/
did you READ the wiki entry? - specifically the xvfb part?
You seem to be running in headless mode ...
Yes, I read it and i ran in headless mode ;) I installed the x-server under Ubuntu 11.04, but as we can read in the article, Tectonicus won't work. But I'll try in 11.10 this evening.