Runtime native extraction fails on 64bit linux

[jediTofu]

So he's using some type of virtual system to put linux on?  Sorry, I'm not familiar with EC2.  I wonder if the LWJGL demos even work on that.  Worst-case scenario, if it's just on EC2, tell people not to use EC2 lol.

I think that I already saw this answered, but it happens using both Open Java and Sun Java, correct?

That's odd that the toolkit solution didn't work, so that might actually not be the bug.  You should be able to try the "awt" solution as well without building LWJGL:

class ... {
  static {
    System.loadLibrary("awt");
    System.setProperty("org.lwjgl.librarypath","...");
    ...
  }
}

[Orangy Tang]

So he's using some type of virtual system to put linux on?  Sorry, I'm not familiar with EC2.  I wonder if the LWJGL demos even work on that.  Worst-case scenario, if it's just on EC2, tell people not to use EC2 lol.

EC2 isn't that complicated really - you just ask amazon for a virtual box of a particular size (micro in this case) and pick one of their preconfigured machine images. But I don't have any experience of it myself. They're almost certainly headless, so probably don't have X installed by default.

I suspect it's more than just an EC2 bug though, because I've had quite a few reports from different people, not all of which are on EC2.

I think that I already saw this answered, but it happens using both Open Java and Sun Java, correct?

I believe so, but I'm horribly confused at the moment as I've got lots of different people all reporting variants on the same bug, so I've kinda lost track.

I'll try the loadLibrary("awt") thing but I'm not hopeful...

[Orangy Tang]

Ok, two user reports, two posts. User one, previously:

System:
   OS Name: Linux
   OS Architecture: i386
   OS Version: 2.6.32-26.1.BHsmp
   Java vendor: Sun Microsystems Inc.
   Java version: 1.6.0_22
   Awt toolkit: null
   Headless?: null
java.lang.UnsatisfiedLinkError: /home2/exiledhe/.tectonicus/native/liblwjgl.so: /home2/exiledhe/mc/jre/jre1.6.0_22/lib/i386/libjawt.so: symbol awt_FreeDrawingSurface, 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(Unknown Source)
   at java.lang.ClassLoader.loadLibrary(Unknown Source)
   at java.lang.Runtime.load0(Unknown Source)
   at java.lang.System.load(Unknown Source)
   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:93)
   at org.lwjgl.Sys.<clinit>(Sys.java:110)
   at org.lwjgl.opengl.Display.<clinit>(Display.java:130)
   at tectonicus.TileRenderer.<init>(TileRenderer.java:82)
   at tectonicus.TectonicusApp.run(TectonicusApp.java:244)
   at tectonicus.TectonicusApp.main(TectonicusApp.java:398)

And with System.loadLibrary("awt"):

System:
        OS Name: Linux
        OS Architecture: i386
        OS Version: 2.6.32-26.1.BHsmp
        Java vendor: Sun Microsystems Inc.
        Java version: 1.6.0_22
        Awt toolkit: null
        Headless?: null
Exception in thread "main" java.lang.UnsatisfiedLinkError: Native Library /home2/exiledhe/mc/jre/jre1.6.0_22/lib/i386/libawt.so already loaded in another classloader
        at java.lang.ClassLoader.loadLibrary0(Unknown Source)
        at java.lang.ClassLoader.loadLibrary(Unknown Source)
        at java.lang.Runtime.loadLibrary0(Unknown Source)
        at java.lang.System.loadLibrary(Unknown Source)
        at tectonicus.TectonicusApp.main(TectonicusApp.java:392)

So I think we can rule out awt not being loaded. Odd that 'awt toolkit' is null - that's the result of System.getProperty("java.awt.toolkit").

[Orangy Tang]

User 2 has the same result as well. First on OpenJDK:

System:
        OS Name: Linux
        OS Architecture: i386
        OS Version: 2.6.34.7-56.40.amzn1.i686
        Java vendor: Sun Microsystems Inc.
        Java version: 1.6.0_20
        Awt toolkit: null
        Headless?: null
Exception in thread "main" java.lang.UnsatisfiedLinkError: /home/ec2-user/.tectonicus/native/liblwjgl.so: /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386/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:1750)
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1646)
        at java.lang.Runtime.load0(Runtime.java:787)
        at java.lang.System.load(System.java:1022)
        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:93)
        at org.lwjgl.Sys.<clinit>(Sys.java:110)
        at org.lwjgl.opengl.Display.<clinit>(Display.java:130)
        at tectonicus.TileRenderer.<init>(TileRenderer.java:82)
        at tectonicus.TectonicusApp.run(TectonicusApp.java:244)
        at tectonicus.TectonicusApp.main(TectonicusApp.java:398)

And then on the sun VM:

System:
        OS Name: Linux
        OS Architecture: i386
        OS Version: 2.6.34.7-56.40.amzn1.i686
        Java vendor: Sun Microsystems Inc.
        Java version: 1.6.0_23
        Awt toolkit: null
        Headless?: null
Settings:
        interactive:false
        worldDir:/home/ec2-user/minecraft/world
        outputDir:/home/ec2-user/minecraft/carto/.
        useCache:true
        cacheDir:/home/ec2-user/minecraft/carto/./cache
        minecraftJar:/home/ec2-user/minecraft/minecraft_server.jar
        texturePack:none
        colourDepth:24
        alphaBits:8
        numSamples:4
        cameraAngle:45
        closestZoomSize:12
        numZoomLevels:8
        imageFormat:png
        eraseOutputDir:false
        extractLwjglNatives:true
        isVerbose:false
        forceLoadAwt:false
        force32BitNatives:true
        force64BitNatives:false

Forcing 32-bit native libraries
Cache directory found and is valid. Using cache at /home/ec2-user/minecraft/carto/./cache
Exception in thread "main" java.lang.UnsatisfiedLinkError: /home/ec2-user/.tectonicus/native/liblwjgl.so: /home/ec2-user/java/jdk1.6.0_23/jre/lib/i386/libjawt.so: symbol awt_FreeDrawingSurface, 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:1803)
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1699)
        at java.lang.Runtime.load0(Runtime.java:770)
        at java.lang.System.load(System.java:1003)
        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:93)
        at org.lwjgl.Sys.<clinit>(Sys.java:110)
        at org.lwjgl.opengl.Display.<clinit>(Display.java:130)
        at tectonicus.TileRenderer.<init>(TileRenderer.java:82)
        at tectonicus.TectonicusApp.run(TectonicusApp.java:244)
        at tectonicus.TectonicusApp.main(TectonicusApp.java:398)

Again, forcing Awt to be loaded just gives the "awt already loaded" exception.

[Matzon]

I assume all of these are on headless environments? if not, either use a terminal launched from X or export the display
Try seeing if xvfb works?
Alternatively, the workaround mentioned that they "might" want to fix this for Java7 - so the latest OpenJDK might have a fix for it.

Anyhow, if someone can create a small executable that dynamically loads libjawt.so in a headless environment preferably by also dlsym JAWT_GetAWT and calling it, then I will try and see it it works for lwjgl too. I did not have any success with it.

[Orangy Tang]

Yes, these are all headless environments. I'll see if they can try the latest OpenJDK.

The sun bug seems to have some code for dynamically loading the libraries at runtime, does that do what you're looking for?

http://bugs.sun.com/view_bug.do?bug_id=6539705

Thanks for looking into this.

[Matzon]

No, I have not been able to make it work with the workaround. Not in LWJGL nor in a seperate test system.
From my POV, this is an Oracle bug, with no clear fix.

See more here: http://lwjgl.org/forum/index.php/topic,3585.msg20180.html#msg20180

So again, try:

• latest OpenJDK
• exporting the display (if possible)
• use xvfb
• make the dlopen/dlsyn of libjawt.so work

[creatis]

Hi,

We've been running into the same error trying to load VTK native libraries from a java program executed on a headless box:

public class Test {
        public static void main(String [] args){
System.loadLibrary("vtkCommonJava");
         System.loadLibrary("vtkFilteringJava");
         System.loadLibrary("vtkIOJava");
         System.loadLibrary("vtkImagingJava");
         System.loadLibrary("vtkGraphicsJava");
         System.loadLibrary("vtkRenderingJava");
        }
}

produces:

java Test
Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/lib64/libvtkRenderingJava.so: /usr/java/jre1.6.0_24/lib/amd64/libjawt.so: symbol awt_FreeDrawingSurface, 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(Unknown Source)
   at java.lang.ClassLoader.loadLibrary(Unknown Source)
   at java.lang.Runtime.loadLibrary0(Unknown Source)
   at java.lang.System.loadLibrary(Unknown Source)
   at Test.main(Test.java:10)

The described workarounds (xvfb and  static{System.loadLibrary("awt");}) didn't work but we solved the issue using the following trick:

[root@kingkong amd64]# pwd
/usr/java/jre1.6.0_24/lib/amd64
[root@kingkong amd64]#
[root@kingkong amd64]# ls -l headless/ xawt/
headless/:
total 36
lrwxrwxrwx 1 root root    47 Jun 30 09:47 libmawt.so -> /usr/java/jre1.6.0_24/lib/amd64/xawt/libmawt.so
-rwxr-xr-x 1 root root 33892 Feb  3 02:25 libmawt.so.old

xawt/:
total 388
-rwxr-xr-x 1 root root 392981 Feb  3 02:25 libmawt.so

This way we're sure to get rid of the buggy headless libmawt ;-)

We have little experience with this lib though; do you think always using the xawt instead of the headless could crash anything?