Error with 64 bit in 2.1.0

Fool Running · March 26, 2009, 15:34:18

Thought I would give the 64 bit a try (I have Windows 7 beta 64).
It works fine when running from a 32 bit JRE, but when trying to run using a 64 bit JRE, I get the following error:

Exception in thread "main" java.lang.UnsatisfiedLinkError: T:\Programming\Java libraries\lwjgl-2.1.0\native\windows\lwjgl.dll: Can't load IA 32-bit .dll on a AMD 64-bit platform
	at java.lang.ClassLoader$NativeLibrary.load(Native Method)
	at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1778)
	at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1703)
	at java.lang.Runtime.loadLibrary0(Runtime.java:823)
	at java.lang.System.loadLibrary(System.java:1030)
	at org.lwjgl.Sys$1.run(Sys.java:72)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.lwjgl.Sys.doLoadLibrary(Sys.java:65)
	at org.lwjgl.Sys.loadLibrary(Sys.java:81)
	at org.lwjgl.Sys.<clinit>(Sys.java:98)
	at org.lwjgl.opengl.AWTGLCanvas.<clinit>(AWTGLCanvas.java:84)

I looked at the code and it looks like this error is supposed to be caught and then the 64 bit .dll is supposed to be loaded. No idea why its failing, but thought I should show the devs.

EDIT: When I try debug the code, it works fine. $:-\$ I'll play around a little more... maybe I have some setting wrong that is messing it up. I hate computers when they don't make any sense.

Matzon · March 26, 2009, 17:52:40

the message above implies that it is trying to load the 32bit dll instead of the 64bit

Fool Running · March 27, 2009, 00:33:12

Yeah, the error message is from the loading of the 32 bit version, but the reason I'm getting that error is that its failing to load the 64 bit version. It spits out the 32 bit error even when failing on the 64 bit one.
When I turn on logging, I get this message:

Failed to load 64 bit library: T:\Programming\Java libraries\lwjgl-2.1.0\native\windows\lwjgl64.dll: %1 is not a valid Win32 application

If no one else is getting this, I'll chalk it up as something to do with Windows 7 or some weird setting on my machine since it works fine when I try to step through the code to debug it.

Matzon · March 27, 2009, 07:01:47

Quote from: Fool Running on March 27, 2009, 00:33:12
Yeah, the error message is from the loading of the 32 bit version, but the reason I'm getting that error is that its failing to load the 64 bit version. It spits out the 32 bit error even when failing on the 64 bit one.
When I turn on logging, I get this message:
Failed to load 64 bit library: T:\Programming\Java libraries\lwjgl-2.1.0\native\windows\lwjgl64.dll: %1 is not a valid Win32 application
If no one else is getting this, I'll chalk it up as something to do with Windows 7 or some weird setting on my machine since it works fine when I try to step through the code to debug it.

well, it is the first time we're donig the 64bit windows stuff - but I have had others test it too.
Can someone comment on whether they got it to work or not (using a 64bit JVM!)?

It does sound odd that it says 'is not a valid Win32 application'?

princec · March 27, 2009, 11:18:30

That rather looks like he's running a 32bit VM.

Cas

Fool Running · March 27, 2009, 16:18:01

Its definitely not the 32bit VM. When I print out the property "java.vm.name", I get "Java HotSpot(TM) 64-Bit Server VM".
I'm wondering if its because there is no 64 bit version of Eclipse for Windows so Eclipse is running in a 32 bit VM while running a 64 bit VM (just a wild guess as I have no idea why running works fine with the 64 bit VM when I'm debugging it

)

If no one else is getting this, I'll just assume its just my machine.

Kiena · March 27, 2009, 23:26:48

I also get the same exception on JDK7b52 under vista (both JVM and OS confirmed to be 64bit of course). When lwjgl.dll is removed, its absence is reported in the form of another exception, so it definitely tries to load that one (I didn't confirm it's due to fallback, but it may very well be the case.)

Tried running the example:
java -cp .;res;jar\lwjgl.jar;jar\lwjgl_test.jar;jar\lwjgl_util.jar;jar\jinput.jar; -Djava.library.path=native\windows org.lwjgl.test.WindowCreationTest

Used command line, so eclipse wasn't involved, although I can confirm that its 32bit version can launch java apps in 64bit just fine. (There is 64bit version of eclipse as well, but for me it produced hanging quite often even without SetPoint (a known cause) running.)

Also note that the readme file in the current release (still?) lists win32 as a possible native folder instead of windows.

Would be nice if this got fixed too, in the next release with OGL 3.1 support.

EDIT: Since for me the problem has been solved (see below), I'll be content with just an official release supporting the 3.1 spec too.

Kiena · March 28, 2009, 00:22:46

With debug enabled the following is logged for me:

Failed to load 64 bit library: C:\Program Files\Java\lwjgl\native\windows\lwjgl64.dll: Can't find dependent libraries

The best I could think of after this was to confirm I have every dll mentioned in lwjgl64.dll in a readable form, but none of them is missing.

Kiena · March 28, 2009, 02:07:12

Found the problem and solution (at least in my case) thanks to this thread:
http://www.realityinteractive.com/rgrzywinski/archives/000219.html
and the Dependency Walker mentioned there.

I added only

<jdk root>/bin

to the path, which was enough so far.

To make the java-related dlls accessible in this case,

<jdk root>/jre/bin

had to be added as well.

EDIT:
Alternative solution is to call

Toolkit.getDefaultToolkit();

before using LWJGL, for example statically in the main class. In this case the path doesn't have to be changed.
/EDIT

I hope this helps some of those who encounter this error.

Matzon · March 28, 2009, 07:17:35

hmm, this may be a delayload issue

The problem is that we're building win64 using mingw, and win32 using visual studio express (command line).

The correct fix may be getting win64 to build using visual studio express (command line) and having the delayload option too.

I assume the dependent dll is jawt.dll ?

Kiena · March 28, 2009, 10:36:28

Quote from: Matzon on March 28, 2009, 07:17:35
I assume the dependent dll is jawt.dll ?

Yep, jawt.dll is the one.

Kiena · March 28, 2009, 14:43:25

After looking around a bit I found out that building 64bit with VS Express is troublesome, and since I have access to a VS8 environment I tried building from source.

The downloadable 2.1.0 source build failed at the compile step because of JInput dependency problems. So instead I continued with the SVN head that passed the mentioned step without problem.

The compile_native step fails this time with the following error:

link:
    [apply]    Creating library lwjgl.lib and object lwjgl.exp
    [apply] LINK : warning LNK4199: /DELAYLOAD:jawt.dll ignored; no imports found from jawt.dll
    [apply] org_lwjgl_opengl_AWTSurfaceLock.obj : error LNK2019: unresolved external symbol __imp__JAWT_GetAWT@8 referenced in function _Java_org_lwjgl_opengl_AWTSurfaceLock_lockAndInitHandle@16
    [apply] lwjgl.dll : fatal error LNK1120: 1 unresolved externals

For quite some time I've very rarely built natives, so I would be grateful for some hint on how to solve its current problem.

Matzon · March 28, 2009, 15:30:34

well, thats where I am at right now ... I can build with mingw - but vs fails on that issue. I *think* it has to do with the JDK being 32bit ?
At least thats what I am experimenting with now - I am installing Windows 7 64 bit and will get all of the stuff 64 bit and see how it fares ...

Matzon · March 28, 2009, 20:00:18

and visual studio express doesn't support 64 bit - sigh

Fool Running · March 30, 2009, 00:43:34

Quote from: Kiena on March 28, 2009, 10:36:28
Quote from: Matzon on March 28, 2009, 07:17:35
I assume the dependent dll is jawt.dll ?

Yep, jawt.dll is the one.

Looks like this was the problem with mine too. I added the directory to the Window's path and it works perfectly.

I wish it would have given me a useful message.

News:

Error with 64 bit in 2.1.0