A long shot: You don’t happen to have some CLASSPATH-variable set in the environment that point to some other LWJGL-jar in some other place?
@jmaasing said: A long shot: You don't happen to have some CLASSPATH-variable set in the environment that point to some other LWJGL-jar in some other place?
LWJGL would then tell something about native version mismatch errors, they do a version check.
Here’s the full error stack at runtime:
[java]$ java -jar av.jar
Exception in thread “main” java.lang.UnsatisfiedLinkError: no lwjgl in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1709)
at java.lang.Runtime.loadLibrary0(Runtime.java:844)
at java.lang.System.loadLibrary(System.java:1051)
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:95)
at org.lwjgl.Sys.<clinit>(Sys.java:112)
at com.jme3.system.lwjgl.LwjglTimer.<clinit>(LwjglTimer.java:59)
at com.devinelabs.av.Main.<init>(Main.java:134)
at com.devinelabs.av.Main.main(Main.java:138)
[/java]
This line looks suspicious:
Java.security.AccessController.doPrivileged
Why doPrivileged?
Because loading a JNI binary by definition allows the app to leave the Java security sandbox. Maybe you have excessive security settings applied to your Java installation?
Probably not, then it would give a Security Exception as well, and not continue to the LoadLibrary method.
There is really only one reason you will get this error:
“no lwjgl in java.library.path”
Reason:
There is no lwjgl in the library path.
If it was a different error then you would get a different message.
The only question is, why is it not there, and for that I strongly suggest to etierh put printlns in the native extract class, or a work with a debugger, and check every step where to find out where it fails.