The attached patch checks os.arch and tries to load the 64bit natives first if it is "amd64"
just out of curiosity "amd64" just looks a bit odd.
Isn't that specific for AMD 64bit processors? what about Intel 64 bit processors?
would "x86_64" not also work but in a vendor neutral way?
amd64 is the string returned by System.getProperty("os.arch")
amd64 does not refer to the used CPU - in fact I have an Intel i5-750 CPU. It refers to the instruction set.
It appears that the implementation uses getPointerSize...so this seems unnecessary.
But the code does seem odd to me:
private static void loadLibrary(final String lib_name) {
try {
doLoadLibrary(lib_name);
} catch (UnsatisfiedLinkError e) {
if (implementation.has64Bit()) {
try {
doLoadLibrary(lib_name + POSTFIX64BIT);
return;
} catch (UnsatisfiedLinkError e2) {
LWJGLUtil.log("Failed to load 64 bit library: " + e2.getMessage());
}
}
// Throw original error
throw e;
}
}
static {
implementation = createImplementation();
loadLibrary(JNI_LIBRARY_NAME);
is64Bit = implementation.getPointerSize() == 8;
//more code....
}
"implementation.has64Bit()": In the Windows implementation class, has64Bit is always true...
"is64Bit = implementation.getPointerSize() == 8;": Shouldn't this be before loadLibrary...but has64Bit is used instead, so I guess it's unnecessary, but that means the 64-bit libs are always trying to be loaded and crashes on 32-bit...but it doesn't crash on 32-bit or else someone would have posted...so I must be confused in the code
I have Windows 7 amd 64-bit, and I know that it fails if I don't have the 64-bit native libs, so to me, it appears everything is working fine and completely unnecessary to do the code you provided. I don't even need the 32-bit native libs even there actually (which makes sense of course) and are completely useless; if 64-bit loading fails, LWJGL doesn't even try to load the 32-bit libs and crashes...
Also, in your code, maybe you could use indexOf "64" instead of equals so that all 64-bit CPU's work...
I updated the patch to check for "amd64" (reported by OpenJDK and Sun JRE on Windows and Ubuntu) and "x86_64" which is mentioned on many websites
We can't use getPointerSize() - it is a native function.
The idea for the RFE is that someone using LWJGL has reports from users where the app fails to start (on Ubuntu 64) when the 32bit natives are loaded first.
Quote from: Matthias on November 26, 2010, 19:25:28
...(on Ubuntu 64) when the 32bit natives are loaded first.
Then what about ppc64?
This would be better to use:
boolean is64bit = osArch.indexOf("64") != -1;
Quote from: Matthias on November 26, 2010, 19:25:28
We can't use getPointerSize() - it is a native function.
The idea for the RFE is that someone using LWJGL has reports from users where the app fails to start (on Ubuntu 64) when the 32bit natives are loaded first.
could you find that post ? I'm running 64bits w7 for a while and my jdk always load 64 bits. 32 bits natives don't run on 64 bits arch.
Quote from: jediTofu on November 26, 2010, 20:27:36
boolean is64bit = osArch.indexOf("64") != -1;
I think this is dangerous as we can't be sure that everything with a 64 in it means a 64 bit OS. This system property has no clear spec. I think testing should be limited to known values.
Also this has no impact on PPC as Mac uses a universal binary. Even if this test should fail to identify a 64bit platform it will just execute the loading order as it was before. To prevent regression this should only change the load order for known 64bit system.
Quote from: broumbroum on November 26, 2010, 21:40:06
Quote from: Matthias on November 26, 2010, 19:25:28
The idea for the RFE is that someone using LWJGL has reports from users where the app fails to start (on Ubuntu 64) when the 32bit natives are loaded first.
could you find that post ? I'm running 64bits w7 for a while and my jdk always load 64 bits. 32 bits natives don't run on 64 bits arch.
The problem with this "someone" is that he refuses to write a bug report. I just created the patch so that he stops to annoy everyone in #lwjgl :)
According to him and his tests loading liblwjgl.so on Ubuntu 64bit (no idea which Ubuntu version) can cause future load attempts of liblwjgl64.so to fail:
Exception in thread "main" java.lang.UnsatisfiedLinkError: /home/bitcoin/DiabloMiner/target/libs/natives/linux/liblwjgl.so: /usr/lib/jvm/java-6-sun-1.6.0.22/jre/lib/amd64/libjawt.so: symbol awt_FreeDrawingSurface, version SUNWprivate_1.1 not defined in file libmawt.so with link time reference
Exception in thread "main" java.lang.UnsatisfiedLinkError: /home/bitcoin/DiabloMiner/target/libs/natives/linux/liblwjgl.so: /home/bitcoin/DiabloMiner/target/libs/natives/linux/liblwjgl.so: wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch)
Maybe an answer to this issue here :D (http://lwjgl.org/forum/index.php/topic,2839.msg15675.html#msg15675)
LWJGL already has 64bit natives for Windows and Linux (MacOSX probably too - I don't have access to a Mac).
The patch Matt made does not solve the problem. It only happens when DISPLAY is unset, which actually is theoretically okay in the use case of headless OpenCL (which my app uses through lwjgl, and three of my users have this problem).
Now that I understand whats going on, I can reproduce it. Do:
unset DISPLAY
./foo
It should output something like:
Exception in thread "main" java.lang.UnsatisfiedLinkError: /foo/natives/linux/liblwjgl.so: /foo/natives/linux/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:1728)
at java.lang.Runtime.loadLibrary0(Runtime.java:823)
at java.lang.System.loadLibrary(System.java:1028)
at org.lwjgl.Sys$1.run(Sys.java:73)
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.opencl.CL.<clinit>(CL.java:51)
at com.foo.main(foo.java:87)
Quote from: Diablo-D3 on November 27, 2010, 17:02:25
The patch Matt made does not solve the problem. ...
And that without even applying the patch - that's a great way to test ...
Quote from: Matthias on November 27, 2010, 17:04:26
Quote from: Diablo-D3 on November 27, 2010, 17:02:25
The patch Matt made does not solve the problem. ...
And that without even applying the patch - that's a great way to test ...
No, I didn't apply it. It doesn't seem like it should be able to fix it. If it does, it still indicates broken behavior somewhere else in lwjgl.
@spasi / matzon any thoughts on this patch? There's been a number of threads/issues on this which above patch remedies (e.g. thread1 (http://lwjgl.org/forum/index.php/topic,3599.0.html), thread2 (http://lwjgl.org/forum/index.php/topic,3617.0.html)), also it has the advantage of not loading the 32bit natives first on 64bit systems like the current code does.
I am not sure about the consequences of the change in behavior. If it works without causing any other grief I don't see why we shouldn't add it.
But I don't have a system for testing the problem... so it'd be nice for someone actually checking that the patch works.
see the thread1 above by OrangyTang (including the linked minecraft forum thread linked in there).
Do we have a reproducible bug or just a random fluke on 1 or more setups?
I fail to see that there is a genuine bug and that this patch fixes it. Orangy Tang mentioned it fixed it for "some".
But if the patch is harmless, I guess it shouldn't be a problem!
fwiw, I'm setting up a 64bit headless environment ... - apparently my server is "only" 32bits - oh well
my local tests show that the patch has no effect.
I have installed a completely basic setup and it basically fails on the fact that Java *really* needs an X server running, even more so when using OpenGL!
The reason for the "wrong ELF class: ELFCLASS32" and similar, is that the exception is thrown when loading the 32bit, whereas the 64bit loading is "silently" failing.
Turning on debug shows this:
QuoteFailed to load 64 bit library: /home/matzon/lwjgl/lwjgl-2.6/native/linux/liblwjgl64.so: libXcursor.so.1: cannot open shared object file: No such file or directory
etc.
fixing all of these (in my case I had to install: libxcursor1, libxrandr2, libxxf86vm1)
and an ldd native/linux/liblwjgl64.so shows:
Quotelinux-vdso.so.1 => (0x00007fff109fc000)
libm.so.6 => /lib/libm.so.6 (0x00007f6bfdeb4000)
libX11.so.6 => /usr/lib/libX11.so.6 (0x00007f6bfdb7e000)
libXext.so.6 => /usr/lib/libXext.so.6 (0x00007f6bfd96b000)
libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x00007f6bfd761000)
libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0x00007f6bfd558000)
libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0x00007f6bfd351000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007f6bfd134000)
libjawt.so => not found
libc.so.6 => /lib/libc.so.6 (0x00007f6bfcdb0000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007f6bfcb94000)
libdl.so.2 => /lib/libdl.so.2 (0x00007f6bfc990000)
libXrender.so.1 => /usr/lib/libXrender.so.1 (0x00007f6bfc785000)
libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x00007f6bfc57f000)
/lib64/ld-linux-x86-64.so.2 (0x00007f6bfe3b8000)
libXau.so.6 => /usr/lib/libXau.so.6 (0x00007f6bfc37b000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007f6bfc174000)
Which is basically what we want.
However running this gives us:
QuoteFailed to load 64 bit library: /home/matzon/lwjgl/lwjgl-2.6/native/linux/liblwjgl64.so: /usr/lib/jvm/java-6-sun-1.6.0.22/jre/lib/amd64/libjawt.so: symbol awt_FreeDrawingSurface, version SUNWprivate_1.1 not defined in file libmawt.so with link time reference
which seems to be caused by a missing function in the headless motif AWT library.
So as per Diablo-D3 I tried to export the display by issuing a 'export DISPLAY=:0'. This failed equally fantastic:
QuoteException in thread "main" java.lang.InternalError: Can't connect to X11 window server using ':0' as the value of the DISPLAY variable.
because ... drum roll ... I don't HAVE a display :)
Instead I installed xvfb, fired it up and exported a display to that - and tada, it works. With AND without the patch!
Of course, it's not all unicorns and rainbows. Access to GL functions seemed severly limited, even with mesa installed.
I think you'd still be best of running a proper X server - if nothing else, then in VNC mode or *anything* that uses proper drivers.
matzon@ubuntu:~/lwjgl/lwjgl-2.6$ java -cp jar/lwjgl.jar:jar/lwjgl_test.jar:jar/lwjgl_util.jar -Dorg.lwjgl.util.Debug=true -Djava.library.path=native/linux/ org.lwjgl.test.opengl.Gears
Could not locate symbol glXCreateContextAttribsARB
Xrandr extension version 1.3
Using Xrandr for display mode switching
Exception in XRandR.populate(): Cannot run program "xrandr": java.io.IOException: error=2, No such file or directory
XF86VidMode extension not available
Initial mode: 800 x 600 x 24 @0Hz
Pixel format info: r = 8, g = 8, b = 8, a = 0, depth = 24, stencil = 0, sample buffers = 0, samples = 0
Could not locate symbol glGetStringi
Could not locate symbol glDrawElementsInstancedBaseVertex
GL_ARB_draw_elements_base_vertex was reported as available but an entry point is missing
Could not locate symbol glClientAttribDefaultEXT
Could not locate symbol glPushClientAttribDefaultEXT
Could not locate symbol glMatrixLoadfEXT
Could not locate symbol glMatrixLoaddEXT
Could not locate symbol glMatrixMultfEXT
Could not locate symbol glMatrixMultdEXT
Could not locate symbol glMatrixLoadIdentityEXT
Could not locate symbol glMatrixRotatefEXT
Could not locate symbol glMatrixRotatedEXT
Could not locate symbol glMatrixScalefEXT
Could not locate symbol glMatrixScaledEXT
Could not locate symbol glMatrixTranslatefEXT
Could not locate symbol glMatrixTranslatedEXT
Could not locate symbol glMatrixOrthoEXT
Could not locate symbol glMatrixFrustumEXT
Could not locate symbol glMatrixPushEXT
Could not locate symbol glMatrixPopEXT
Could not locate symbol glTextureParameteriEXT
Could not locate symbol glTextureParameterivEXT
Could not locate symbol glTextureParameterfEXT
Could not locate symbol glTextureParameterfvEXT
Could not locate symbol glTextureImage1DEXT
Could not locate symbol glTextureImage2DEXT
Could not locate symbol glTextureSubImage1DEXT
Could not locate symbol glTextureSubImage2DEXT
Could not locate symbol glCopyTextureImage1DEXT
Could not locate symbol glCopyTextureImage2DEXT
Could not locate symbol glCopyTextureSubImage1DEXT
Could not locate symbol glCopyTextureSubImage2DEXT
Could not locate symbol glGetTextureImageEXT
Could not locate symbol glGetTextureParameterfvEXT
Could not locate symbol glGetTextureParameterivEXT
Could not locate symbol glGetTextureLevelParameterfvEXT
Could not locate symbol glGetTextureLevelParameterivEXT
Could not locate symbol glTextureImage3DEXT
Could not locate symbol glTextureSubImage3DEXT
Could not locate symbol glCopyTextureSubImage3DEXT
Could not locate symbol glBindMultiTextureEXT
Could not locate symbol glMultiTexCoordPointerEXT
Could not locate symbol glMultiTexEnvfEXT
Could not locate symbol glMultiTexEnvfvEXT
Could not locate symbol glMultiTexEnviEXT
Could not locate symbol glMultiTexEnvivEXT
Could not locate symbol glMultiTexGendEXT
Could not locate symbol glMultiTexGendvEXT
Could not locate symbol glMultiTexGenfEXT
Could not locate symbol glMultiTexGenfvEXT
Could not locate symbol glMultiTexGeniEXT
Could not locate symbol glMultiTexGenivEXT
Could not locate symbol glGetMultiTexEnvfvEXT
Could not locate symbol glGetMultiTexEnvivEXT
Could not locate symbol glGetMultiTexGendvEXT
Could not locate symbol glGetMultiTexGenfvEXT
Could not locate symbol glGetMultiTexGenivEXT
Could not locate symbol glMultiTexParameteriEXT
Could not locate symbol glMultiTexParameterivEXT
Could not locate symbol glMultiTexParameterfEXT
Could not locate symbol glMultiTexParameterfvEXT
Could not locate symbol glMultiTexImage1DEXT
Could not locate symbol glMultiTexImage2DEXT
Could not locate symbol glMultiTexSubImage1DEXT
Could not locate symbol glMultiTexSubImage2DEXT
Could not locate symbol glCopyMultiTexImage1DEXT
Could not locate symbol glCopyMultiTexImage2DEXT
Could not locate symbol glCopyMultiTexSubImage1DEXT
Could not locate symbol glCopyMultiTexSubImage2DEXT
Could not locate symbol glGetMultiTexImageEXT
Could not locate symbol glGetMultiTexParameterfvEXT
Could not locate symbol glGetMultiTexParameterivEXT
Could not locate symbol glGetMultiTexLevelParameterfvEXT
Could not locate symbol glGetMultiTexLevelParameterivEXT
Could not locate symbol glMultiTexImage3DEXT
Could not locate symbol glMultiTexSubImage3DEXT
Could not locate symbol glCopyMultiTexSubImage3DEXT
Could not locate symbol glEnableClientStateIndexedEXT
Could not locate symbol glDisableClientStateIndexedEXT
Could not locate symbol glGetFloatIndexedvEXT
Could not locate symbol glGetDoubleIndexedvEXT
Could not locate symbol glGetPointerIndexedvEXT
Could not locate symbol glEnableIndexedEXT
Could not locate symbol glDisableIndexedEXT
Could not locate symbol glIsEnabledIndexedEXT
Could not locate symbol glGetIntegerIndexedvEXT
Could not locate symbol glGetBooleanIndexedvEXT
Could not locate symbol glNamedProgramStringEXT
Could not locate symbol glNamedProgramLocalParameter4dEXT
Could not locate symbol glNamedProgramLocalParameter4dvEXT
Could not locate symbol glNamedProgramLocalParameter4fEXT
Could not locate symbol glNamedProgramLocalParameter4fvEXT
Could not locate symbol glGetNamedProgramLocalParameterdvEXT
Could not locate symbol glGetNamedProgramLocalParameterfvEXT
Could not locate symbol glGetNamedProgramivEXT
Could not locate symbol glGetNamedProgramStringEXT
Could not locate symbol glCompressedTextureImage3DEXT
Could not locate symbol glCompressedTextureImage2DEXT
Could not locate symbol glCompressedTextureImage1DEXT
Could not locate symbol glCompressedTextureSubImage3DEXT
Could not locate symbol glCompressedTextureSubImage2DEXT
Could not locate symbol glCompressedTextureSubImage1DEXT
Could not locate symbol glGetCompressedTextureImageEXT
Could not locate symbol glCompressedMultiTexImage3DEXT
Could not locate symbol glCompressedMultiTexImage2DEXT
Could not locate symbol glCompressedMultiTexImage1DEXT
Could not locate symbol glCompressedMultiTexSubImage3DEXT
Could not locate symbol glCompressedMultiTexSubImage2DEXT
Could not locate symbol glCompressedMultiTexSubImage1DEXT
Could not locate symbol glGetCompressedMultiTexImageEXT
Could not locate symbol glMatrixLoadTransposefEXT
Could not locate symbol glMatrixLoadTransposedEXT
Could not locate symbol glMatrixMultTransposefEXT
Could not locate symbol glMatrixMultTransposedEXT
Could not locate symbol glNamedBufferDataEXT
Could not locate symbol glNamedBufferSubDataEXT
Could not locate symbol glMapNamedBufferEXT
Could not locate symbol glUnmapNamedBufferEXT
Could not locate symbol glGetNamedBufferParameterivEXT
Could not locate symbol glGetNamedBufferPointervEXT
Could not locate symbol glGetNamedBufferSubDataEXT
Could not locate symbol glProgramUniform1fEXT
Could not locate symbol glProgramUniform2fEXT
Could not locate symbol glProgramUniform3fEXT
Could not locate symbol glProgramUniform4fEXT
Could not locate symbol glProgramUniform1iEXT
Could not locate symbol glProgramUniform2iEXT
Could not locate symbol glProgramUniform3iEXT
Could not locate symbol glProgramUniform4iEXT
Could not locate symbol glProgramUniform1fvEXT
Could not locate symbol glProgramUniform2fvEXT
Could not locate symbol glProgramUniform3fvEXT
Could not locate symbol glProgramUniform4fvEXT
Could not locate symbol glProgramUniform1ivEXT
Could not locate symbol glProgramUniform2ivEXT
Could not locate symbol glProgramUniform3ivEXT
Could not locate symbol glProgramUniform4ivEXT
Could not locate symbol glProgramUniformMatrix2fvEXT
Could not locate symbol glProgramUniformMatrix3fvEXT
Could not locate symbol glProgramUniformMatrix4fvEXT
Could not locate symbol glProgramUniformMatrix2x3fvEXT
Could not locate symbol glProgramUniformMatrix3x2fvEXT
Could not locate symbol glProgramUniformMatrix2x4fvEXT
Could not locate symbol glProgramUniformMatrix4x2fvEXT
Could not locate symbol glProgramUniformMatrix3x4fvEXT
Could not locate symbol glProgramUniformMatrix4x3fvEXT
Could not locate symbol glNamedProgramLocalParameters4fvEXT
Could not locate symbol glNamedRenderbufferStorageEXT
Could not locate symbol glGetNamedRenderbufferParameterivEXT
Could not locate symbol glNamedRenderbufferStorageMultisampleEXT
Could not locate symbol glCheckNamedFramebufferStatusEXT
Could not locate symbol glNamedFramebufferTexture1DEXT
Could not locate symbol glNamedFramebufferTexture2DEXT
Could not locate symbol glNamedFramebufferTexture3DEXT
Could not locate symbol glNamedFramebufferRenderbufferEXT
Could not locate symbol glGetNamedFramebufferAttachmentParameterivEXT
Could not locate symbol glGenerateTextureMipmapEXT
Could not locate symbol glGenerateMultiTexMipmapEXT
Could not locate symbol glFramebufferDrawBufferEXT
Could not locate symbol glFramebufferDrawBuffersEXT
Could not locate symbol glFramebufferReadBufferEXT
Could not locate symbol glGetFramebufferParameterivEXT
Could not locate symbol glNamedCopyBufferSubDataEXT
GL_EXT_direct_state_access was reported as available but an entry point is missing
Could not locate symbol glPrimitiveRestartNV
Could not locate symbol glPrimitiveRestartIndexNV
GL_NV_primitive_restart was reported as available but an entry point is missing
LWJGL: 2.6 / linux
GL_VENDOR: Mesa Project
GL_RENDERER: Software Rasterizer
GL_VERSION: 2.1 Mesa 7.7.1
glLoadTransposeMatrixfARB() supported: true
2242 frames in 4.999 seconds = 448.4897
2259 frames in 5.0 seconds = 451.8So to sum up:
* Patch not needed
* xvfb possible workaround
With regards to the workaround in http://bugs.sun.com/view_bug.do?bug_id=6539705 - I am not able to get it to work.
I keep getting the same error: symbol awt_FreeDrawingSurface, version SUNWprivate_1.1 not defined in file libmawt.so with link time reference
I replaced his LOAD_LIBRARY and FIND_ENTRY with dlopen (, RTLD_LAZY) and dlsym
If someone can load awt in a headless environment (java 1.6) please let me know.
Unable to get the following working from a test program (32 bits, same issue)
#include <stdio.h>
#include <stdlib.h>
#include <dlfcn.h>
#include <jni.h>
#include <jawt_md.h>
static void* jawt_handle = NULL;
static jboolean (JNICALL *pJAWT_GetAWT)(JNIEnv*,JAWT*);
#define JAWT_GetAWT (*pJAWT_GetAWT)
int
main(int argc, char **argv)
{
void *jawt_handle;
char *error;
jawt_handle = dlopen("/usr/lib/jvm/java-6-sun/jre/lib/i386/libjawt.so", RTLD_LAZY|RTLD_GLOBAL);
if (!jawt_handle) {
fprintf(stderr, "unable to load jawt.so: %s\n", dlerror());
exit(EXIT_FAILURE);
}
dlerror(); /* Clear any existing error */
//jawt_getawt = (JAWT_GetAWT) dlsym(jawt_handle, "JAWT_GetAWT");
//result = jawt_getawt(env, &awt);
if ((error = dlerror()) != NULL) {
fprintf(stderr, "%s\n", error);
exit(EXIT_FAILURE);
}
dlclose(jawt_handle);
exit(EXIT_SUCCESS);
}Quotegcc -rdynamic -o awt2 awt2.cpp -ldl -lstdc++ -I/usr/lib/jvm/java-6-sun/include -I/usr/lib/jvm/java-6-sun/include/linux
Quotematzon@nesquick ~/lwjgl> cat /etc/ld.so.conf.d/java.conf
/usr/lib/jvm/java-6-sun/jre/lib/i386/
/usr/lib/jvm/java-6-sun/jre/lib/i386/headless
/usr/lib/jvm/java-6-sun/jre/lib/i386/server
Quoteunable to load jawt.so: /usr/lib/jvm/java-6-sun/jre/lib/i386/libjawt.so: symbol awt_FreeDrawingSurface, version SUNWprivate_1.1 not defined in file libmawt.so with link time reference
Might need to be some JNI with preloaded AWT - not sure
Could System.setProperty("java.awt.headless", "true"); and using Toolkit only possibly fix this?
Source: http://java.sun.com/developer/technicalArticles/J2SE/Desktop/headless/
I stumbled upon this thread today, since i'm trying to use slick in my Eclipse project and i'm getting the error described in this post. Unfortunately nothing helped up to now.
I have a windows7 64bit with a 64bit jre running. And i am getting this error:
java.lang.UnsatisfiedLinkError: C:\Users\ckosmowski\workspace\wusel\native\windows\jinput-dx8.dll: Can't load IA 32-bit .dll on a AMD 64-bit platform
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
I can't seem to get this fixed and from all the answers here and on other forums i can't see what the solution would be. Shouldn't this be fixed in the new lwjgl version? (I'm using 2.7.1)
It is called AMD 64 simply because AMD's lawyers won the race to the trademark/patent office. Intel licensed AMD's 64 bit architecture for their own use because the design was much more efficient and ran at lower power. Oddly enough, Intel wound up managing said power usage and heat management better in the finished product, as anyone who has had an AMD x2 64 laptop heatsink burn their leg would tell you, lol!
Trying to get started with slick.
I am having the same issue, and the patch doesn't help. Or i am just not doing it right.