Another java.lang.UnsatisfiedLinkError: no lwjgl in java.library.path issue

Started by Rudster, January 27, 2016, 09:00:19

Previous topic - Next topic

Rudster

I know this pops up all over the place but I have gone through all the topics on this issue in both this forum and Stack Overflow and they keep saying the same thing. Check that you have correctly set the Native library location. The thing is I have checked and rechecked the build path and everything is correct. but I still end up with this error and running the exported jar.

C:\Users\Rudster>java -jar C:\Users\Rudster\Desktop\Flappy\Flappy.jar
Exception in thread "Game" java.lang.UnsatisfiedLinkError: no lwjgl in java.library.path
        at java.lang.ClassLoader.loadLibrary(Unknown Source)
        at java.lang.Runtime.loadLibrary0(Unknown Source)
        at java.lang.System.loadLibrary(Unknown Source)
        at org.lwjgl.system.Library.loadSystem(Library.java:100)
        at org.lwjgl.system.Library.<clinit>(Library.java:48)
        at org.lwjgl.system.MemoryAccess.<clinit>(MemoryAccess.java:22)
        at org.lwjgl.system.Pointer.<clinit>(Pointer.java:24)
        at org.lwjgl.glfw.GLFW.<clinit>(GLFW.java:594)
        at com.therudster.flappy.Main.init(Main.java:37)
        at com.therudster.flappy.Main.run(Main.java:88)
        at java.lang.Thread.run(Unknown Source)

The program runs within eclipse with no issues. but exported it wont.
Here is the build path


I have tried Release, stable and nightly builds and they all come up with the same error. I am running Windows 10 Pro and Eclipse Mars 4.5.1.

Im lost as to why I cant get a runnable jar.

Here is a pastebin of my main if you need it
http://pastebin.com/yHEmrwyA

abcdef

What things have you tried, this looks less about building and more about running. The error says it can't find the dll's/so's/etc as specified by  java.library.path and you haven't specified this in your java command. With out seeing what is in the jar manifest file its going to be hard to know if it is missing entirely or not setup right.

If you want to know more details as to what it is doing to try and load the library. have a look at

https://github.com/LWJGL/lwjgl3/blob/master/modules/core/src/main/java/org/lwjgl/system/Library.java


Kai

Eclipse does not export the java.library.path into any kind of MANIFEST or something else when building a runnable jar, because VM/system parameters cannot be set in the MANIFEST.
If your Eclipse setup is that you have a local file system folder where you keep the DLLs and set this folder as the java.library.path either on your Build Path settings on some library's "Native library location" or as a VM/system property in your run configuration via "-Djava.library.path", then this setting WILL NOT be exported when bilding a runnable jar.

Long story short: You can spare yourself all that trouble if you just download the lwjgl-platform artifacts and just reference these as normal JAR files in your project. Those platform JAR files contain the DLLs inside the JAR file. When being run, LWJGL will extract those DLLs once from the JAR into a temporary folder of your user and it'll work nicely.

When exporting it from Eclipse via building a runnable Jar, Eclipse will extract the contents of the JAR into your runnable JAR (or copy those JARs into a lib folder of your runnable jar, depending on the settings you use during export).
Either way, it'll just work without you having to specify any folder location.

Taking this a step further, you can even make use of Maven or Gradle for this, where you:
1. always automatically get the latest versions of the library
2. don't even have to manually download and extract the JAR/DLL files into some file system folder

Rudster

Sorry for being so new to all of this. Including the corresponding native jar bypassed my issue though it appears I have much to learn when it comes to exporting programs. (Apparently I dont know how to correctly package my shaders nor textures.) Thank you for the help though.

Kai

Generally, I'd always advise you to use a classpath resource.
This means: Having some "resource"/"res" folder in your project which is also in the classpath/buildpath.
In Eclipse: Rightlick on the folder -> "Build Path" -> "Use as Source Folder"
Then have all your textures and shaders in some folder inside there.
And then load those resources not via some java.io.File from the file system but using the ClassLoader.
For example like so:
InputStream is = ClassLoader
   .getSystemClassLoader()
   .getResourceAsStream("/textures/texture.png");

where you would have the file "texture.png" inside that resource classpath folder in the "package" "textures".

This will both work inside Eclipse and also automagically when exporting the application as runnable jar. :)

Rudster

The methods I was taught to use relies of BufferedReader, FileReader and ImageIO which with no source folder though using res and shaders folders packaged along side the .jar. Obviously this works but isnt the cleanest method.

Ignoring the above issue, the issue I only have left is one that has me scratching my head. As usual it works fine in eclipse but with the external jar it doesnt.

Keyboard inputs rather than initiating methods within the program force close the game. Im sure this is something simple I have missed but lack of experience lol

public class Input extends GLFWKeyCallback {

	public static boolean[] keys = new boolean[65536];
	
	public void invoke(long window, int key, int scancode, int action, int mods) {
		keys[key] = action != GLFW.GLFW_RELEASE;
	}
	
	public static boolean isKeyDown(int keycode){
		return keys[keycode];
	}	
}


in main
glfwSetKeyCallback(window, new Input());


used like this
Input.isKeyDown(GLFW_KEY_SPACE)