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. :P
the message above implies that it is trying to load the 32bit dll instead of the 64bit
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.
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'?
That rather looks like he's running a 32bit VM.
Cas :)
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 :P)
If no one else is getting this, I'll just assume its just my machine. ;D
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.
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.
Found the problem and solution (at least in my case) thanks to this thread:
http://www.realityinteractive.com/rgrzywinski/archives/000219.html (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/binhad to be added as well.
EDIT:
Alternative solution is to callToolkit.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.
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 ?
Quote from: Matzon on March 28, 2009, 07:17:35
I assume the dependent dll is jawt.dll ?
Yep, jawt.dll is the one.
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.
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 ...
and visual studio express doesn't support 64 bit - sigh
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. ;D
I wish it would have given me a useful message. ;)
could you try a Toolkit.getDefaultToolkit(); prior to using LWJGL - it can possibly load the jawt.dll for you
I'll try later and report the results. (Very little time during the week that's why I didn't post in the win64 tester recruiting thread.)
By the way, I wonder how many awt classes are loaded this way that wouldn't be if they were not otherwise used. (It may be desirable to avoid loading most of them if lwjgl provides their functionality through other and/or native apis.)
A static call to Toolkit.getDefaultToolkit() indeed solved the problem as well.
Getting the default toolkit was the solution in this case too:
http://lwjgl.org/forum/index.php/topic,2847.0.html (http://lwjgl.org/forum/index.php/topic,2847.0.html)
Does Sys.alert(String, String) have similar issues or that problem is unrelated?
I really dont know why Sys.alert is misbehaving ...
however, we are talking about adding getDefaultToolkit to lwjgl itself - which should be fine (unless you're doing awt-less stuff, then you have to remove it).
Quote from: Matzon on March 30, 2009, 11:18:51
could you try a Toolkit.getDefaultToolkit(); prior to using LWJGL - it can possibly load the jawt.dll for you
That didn't fix it for me. I had to add jre\bin to PATH.
(Win7, Java 1.6 Update 13, no 32bit JDK/JRE installed)
are you sure you are calling it BEFORE *any* LWJGL references?
try adding some System.out when calling Toolkit and then add -Dorg.lwjgl.util.Debug=true and see which spit something out first.
For some reason, I thought this issue was resolved. Just looked again because I installed the latest W7 release and was getting this problem again.
I tried the Toolkit.getDefaultToolkit(); and it didn't work for me either. I'm sure its called before any LWJGL as its the first thing in my main() method.
Adding the jre/bin to the path did help, still.
EDIT:
Using Windows 7, JRE1.6.0_13. My application uses an AWTGLCanvas inside a Frame, so I would think it would load the toolkit anyways.
I'll try do some more testing.
I just tried the latest from nightly on windows 7 64bit, java 1.6.0_14ea 64bit and no problems at all ... I do have a dev environment installed - not sure if that changes anything tho?
I got it working, but its kinda strange.
I wasn't using the JRE like I thought I was :-[, I was using the JDK. When using the 64 bit JDK it fails no matter what I try unless I add the jre/bin to the path. But when using the 64 bit JRE it works fine. I don't even need the Toolkit.getDefaultToolkit() fix (which is what I expected since I use a AWTGLCanvas in a Frame).
I have no explanation as to why using the JDK always fails, though. ;D
EDIT: I looked closer at my Eclipse settings... I'm wondering if it has something to do with the way Eclipse sets up the JDK. It might look at <jdk path>/bin for stuff when the .dll is actually in <jdk path>/jre/bin. This is just grasping at straws as I wouldn't think any AWT would work without these .dlls being loaded properly.
Has anyone else tried this in Eclipse, setup with a JDK?
I was testing from command line.
Yeah, it looks like it was just Eclipse not being set up quite right. The command line works fine for me.
Sorry for the false alarm. :P