A lot of people using Linux seem to have issues using jME3, because the native extraction system isn't working as intended. There are several natives used for lwjgl, there's a 32 bit version and a 64 bit version, jME3 extracts the version depending on architecture (x86 or amd64/x64) to the working directory. This works fine in Windows but in Linux it doesn't work unless you add the working directory to PATH (right?). Also another person said that renaming the lwjgl64 library to lwjgl was also required…
The other problem I ran into was jme3 itself, it couldn't find lwjgl. I tried forcing the java library path to a folder with the extracted natives but it didn't work either, I had to rename all the 64 natives and remove the "64" in order for them to be found with the explicit library path. I later discovered a liblwjgl64.so dropped in an unusual place, the root of the project, probably the running directory when using linux, that is were it must have been auto extracted. To avoid this issue with gde too in the end I copied the natives to my jre (with the 64 removed).
What the heck? I swear I had jME3 working on my Ubuntu 64 bit before..
So, question is, how do I accomplish the native library extraction in such way that it works on all Linux systems?
Its not a problem with your code as much as it is whether or not the user has added the current working directory to the LD_LIBRARY_PATH variable (it is not by default on linux for security reasons). So, my suggestion is to just add -Djava.library.path=<current working directory> to the command line. On linux (and unix) the jvm does not add the working directory to the afore mentioned env variable like other platforms so you could try adding this "LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH" to the environment through java though I don't know if it will be picked up after the jvm starts even if you do it before the the calls to System.mapLibraryName(lib) and System.loadLibrary(lib) but it might be worth a try with System.setProperty("java.library.path", "<current working directory>").
to get lwjgl natives to work on all platforms you simply point to the folder that contains them with the following code
// add natives files path to native class path
System.setProperty("org.lwjgl.librarypath", pathToNatives);
// Make sure jinput knows about the new path too
System.setProperty("net.java.games.input.librarypath", pathToNatives);
Yes I know about that work around, do you know anything about the other issue where removing the *64 suffix from lwjgl64 helped get it working? Also, is there any hope for JOGL if using the native extraction?
After some hacking on "com.jme3.system.Natives.java" and some googleing the answer is no unless you just add the current working directory to java.library.path. I tried to manipulate this property by appending the current working directory with a call to setProperty before calling loadLibrary but this had no effect even though java sees the change to the system property. If I used the System.load("<fullpath>") with each library it worked for lwjgl but not jogl because it calls into gluegen-rt and this effectively calls System.loadLibrary which needs LD_LIBRARY_PATH to be set properly. It seems that on linux and unix the system property "java.library.path" is populated with LD_LIBRARY_PATH and all changes to "java.library.path" are ignored unless it is set before launching the vm. So if your using linux you have two courses of action, 1.) change your LD_LIBRARY_PATH to include the current working directory (not secure) or 2.) just add the current working directory to the java.library.path on the command line (only the directory is needed not each library).
For consistency's sake I am going to remove JOGL extraction for all platforms, even though it only fails on Linux.
Uh, why not leave it in and tell linux users to add the local folder to the classpath? I think its a great feature and maybe theres gonna be a workaround sooner or later..
Also, is there any hope for JOGL if using the native extraction?
can't speak for jogl, but guess you can request that as a feature for next release if its not already implemented.
Momoko_Fan said:
Yes I know about that work around, do you know anything about the other issue where removing the *64 suffix from lwjgl64 helped get it working?
hmm strange, I use linux64 myself and not seen this issue nor have I seen it reported for any of the recent LWJGL releases, btw which version of LWJGL are you using? (could also be that the ubuntu user has a 32 jre installed on his 64bit system but again shouldn't cause this issue).