Runtime native extraction fails on 64bit linux

[Orangy Tang]

I have a user on 64bit linux reporting the following exception on startup:

Exception in thread "main" java.lang.UnsatisfiedLinkError: /home/minecraft/.tectonicus/native/liblwjgl.so: /home/minecraft/.tectonicus/native/liblwjgl.so: wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch)
        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:82)
        at org.lwjgl.Sys.<clinit>(Sys.java:99)
        at org.lwjgl.opengl.Display.<clinit>(Display.java:130)

What I do is ship the native files dll/so/etc. inside my jar, and then extract them to a temporary directory at startup, then set the system property. All this happens before any LWJGL calls.

private void unpackLwjgl()
	{
		String[] files =
		{
			"jinput-dx8_64.dll",
			"jinput-dx8.dll",
			"jinput-raw_64.dll",
			"jinput-raw.dll",
			"libjinput-linux.so",
			"libjinput-linux64.so",
			"libjinput-osx.jnilib",
			"liblwjgl.jnilib",
			"liblwjgl.so",
			"liblwjgl64.so",
			"libopenal.so",
			"libopenal64.so",
			"lwjgl.dll",
			"lwjgl64.dll",
			"openal.dylib",
			"OpenAL32.dll",
			"OpenAL64.dll"
		};
		
		File cacheDir = new File(System.getProperty("user.home"), ".tectonicus/native");
		cacheDir.mkdirs();
		for (String f : files)
		{
			File outFile = new File(cacheDir, f);
			FileUtils.extractResource("Native/"+f, outFile);
		}
		
		String nativePath = cacheDir.getAbsolutePath();
		System.setProperty("org.lwjgl.librarypath", nativePath);
		System.setProperty("net.java.games.input.librarypath", nativePath);
	}

This works on OSX, WinXp, Win7 (personally tested) and I believe on 32bit linux,  but not on 64bit linux. It looks like it's trying to use the non-64bit native library.

I'm not sure what would cause this behaviour - is there another step I'm missing? Alternatively, does anyone know how I can get more information on exactly what might be going wrong?

Thanks.

[kappa]

which version of LWJGL are you using? I remember this was a bug on the early 2.x releases but was fixed in a subsequent LWJGL release.

[Matthias]

This is the error for which I wrote that RFE While the original reporter still has not tested it.

[Orangy Tang]

That does sound like my issue (running headless on ubuntu 64bit).

I don't have a linux box handy - if you could provide me with a binary build I could get my user to test it and report back? That would be greatly appreciated.

[Matthias]

I don't have a linux box handy - if you could provide me with a binary build I could get my user to test it and report back? That would be greatly appreciated.

I send you the link to the lwjgl.jar via PM. It is a patch LWJGL 2.6

[Orangy Tang]

Hmm, no dice. It now fails with this exception:

org.lwjgl.LWJGLException: X Error - disp: 0x7f65b01dce10 serial: 58 error: BadRequest (invalid request code or no such operation) request_code: 155 minor_code: 179
        at org.lwjgl.opengl.LinuxDisplay.globalErrorHandler(LinuxDisplay.java:277)
        at org.lwjgl.opengl.GL11.nglGetError(Native Method)
        at org.lwjgl.opengl.GL11.glGetError(GL11.java:1280)
        at org.lwjgl.opengl.Util.checkGLError(Util.java:57)

However I don't know if that's a related error or a new one. Is there anything else I can try? (note this happens after pbuffer creation, so it's getting past that point at least).

[jediTofu]

Just for testing purposes, you could try having your "String[] files" array only contain the 64-bit linux versions, and try using both your original lwjgl.jar and the one by Matthias.

What is the code at the "BadRequest" line?

[Orangy Tang]

Just for testing purposes, you could try having your "String[] files" array only contain the 64-bit linux versions, and try using both your original lwjgl.jar and the one by Matthias.

What is the code at the "BadRequest" line?

I think it's finding the right version now (since it's not complaining about the architecture version mismatch), but I'm not sure what this new error is.

The calling code is actually a direct call to checkGLError, just after I've done some vertex array setup. Since it happens on the first frame, i suspect it's the first time checkGlError is being called after Pbuffer.makeCurrent().

Some googling suggests that 'request code 155' might be a X11 code for 'bad gl context', but I don't know what the second code is, nor why I'm getting 'bad gl context' after seemingly creating a pbuffer without a problem.

Hopefully someone more familiar with X and linux can give me some pointers.

[jediTofu]

Is there a way I can try the actual program?

I finally got around to testing LWJGL on Linux Mint 64-bit (Ubuntu Based).  I did all of the LWJGL demos, and they worked fine.

[Orangy Tang]

Is there a way I can try the actual program?

I finally got around to testing LWJGL on Linux Mint 64-bit (Ubuntu Based).  I did all of the LWJGL demos, and they worked fine.

Sure, you can download it from the first post in this thread: http://www.minecraftforum.net/viewtopic.php?f=25&t=95739

Also contains an ever growing number of people on linux having display exceptions too.

[jediTofu]

It worked for me; there's probably more that I need to do though or something.

Info:

java -version output:
java version "1.6.0_20"
Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode)

uname -a output:
Linux mint 2.6.35-22-generic #33-Ubuntu SMP Sun Sep 19 20:32:27 UTC 2010 x86_64 GNU/Linux


Here's what I did:

I used MCmapper to create a level for me (i.e., level.dat).

Then I played Single Player in order to get minecraft.jar.
Then I searched my file system for it and ran this command after I found it:

java -jar Tectonicus.jar minecraftJar=/tmp/www.minecraft.net/Minecraft/minecraft.jar  worldDir=./world outputDir=./map numSamples=0

[Orangy Tang]

Well I'm glad it's not totally buggered on linux - I've got the usual problem that I'm only really hearing a lot of noise from people who it doesn't work for, so it's nice to see a report of it working cleanly.

I'll admit to feeling a little lost, especially on reports like this one: http://www.minecraftforum.net/viewtopic.php?f=25&t=95739&start=210#p1532749

[jediTofu]

Well I'm glad it's not totally buggered on linux - I've got the usual problem that I'm only really hearing a lot of noise from people who it doesn't work for, so it's nice to see a report of it working cleanly.

I'll admit to feeling a little lost, especially on reports like this one: http://www.minecraftforum.net/viewtopic.php?f=25&t=95739&start=210#p1532749

Hmmm, ok, have you had them try using sudo?

sudo java -jar Tectonicus.jar ...

If that doesn't work, then you'll have to modify Sys.java to have 'System.loadLibrary("awt");' like the bug link you posted in your other thread, which would make this an actual bug.

Out of curiosity, the patched lwjgl Matthias did work for the original problem?  I guess that means that patch needs to be added in the main version as well.

[Orangy Tang]

1. Matthias's jar patch does solve the original problem for some people, yes. So that definitely needs to go in.

2. I'll ask them about sudo.

3. I've already manually added a Toolkit.getDefaultToolkit() (supposed to be more effective than System.loadLibrary("awt") since it copes better with headless environments), but that didn't help.

[Orangy Tang]

Further info:

sudo didn't help.

It is a headless 32-bit Linux Amazon EC2 instance

http://aws.amazon.com/free/

Which is interesting, since I assumed it was a 64bit issue.