I’ve been trying to make sure that JME is working as expected on my system (Arch Linux - VirtualBox guest on a Windows 10 host - tried with multiple different jdks)
using gradle run will get me the test selector (yay!) and selecting a test will pop the resolution/graphics settings splash (when the test uses it)
However, when selecting continue on any test that requires bullet, I get:
java.lang.UnsatisfiedLinkError: The required native library 'bulletjme' was not found in the classpath via 'native/linux/x86_64/libbulletjme.so'. Error message: no bulletjme in java.library.path
this, even though at the beginning of the gradle run, it claims:
Use natives snapshot: https://dl.bintray.com/jmonkeyengine/files/a4c694ba36258af5c6ce7823f4bdacc424988557/jme3-natives.zip
I’ve checked, and that URL is legitimate. (I can download with a browser, and it has the correct .so included)
Any idea why the gradle scripts are not making sure the correct library is on the path?
this is wrapper lib, but it still require “implementation lib” like:
compile "org.jmonkeyengine:jme3-bullet-native:$jmeVersion (or java version jBullet that is outdated)
im not sure how gradle JME Tests Project build work(i thought its only Ant), because i use Ant JME Tests, but using gradle Project for game and im sure it need “both bullet wrapper + native/implementation lib” to work.
For me libbulletjme.so were working on Ubuntu, Windows 8.1 and Centos 8 without issues(if builded properly). so i dont think it’s system related.
I would also suggest you to “clean and build” project - it might help too.
I’m actually talking about running the jmonkeyengine repository build, not my own project. Not a big fan of SDKs in general, they seem to tend to do “magic” under the surface that I then have to reverse-engineer for my own, independent builds.
Well, in either case, I cannot build native either. I’ve tried to force the bullet Linux shared library target, and the builds fail, complaining that it can’t find jni.h
File definitely exists, I even went as far as hard-coding the location in jme3-bullet-natives/build.gradle instead of relying on the auto- detection. Still claims it does not exist. Wierd.
If the Gradle builds don’t work, how is the engine built for release?
Based on my experience(Using Centos 7), some OpenJDK builds had broken link to jni.h that required /include before it(or remove it, i dont remember now). Anyway it might be system related.
I’ve reproduced the reported issue using Windows 7, master-branch JME, and gradlew.
I believe it is related to recent changes in the master branch. After I rolled my repo back to 9 October (hash=b1db497a0027ae7f142be5c5f2852539196a1d70) I was able to run physics examples from TestChooser just fine.
(I didn’t get a chance to try @sgold’s workaround - fix had been posted before I had some time to work on programming stuff. I do appreciate the effort, though!)
I’m running into other issues that seem to be more OS/virtualbox related. Maybe time to switch to VMWare? Really did not want to have to re-build my dev setup from scratch.