[SOLVED] Running Examples from command line (Gradle) - missing bulletjme

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?

1 Like

i were using JME Tests via SDK (Ant not Gradle), but gradle should run fine too i think. Or you mean wiki examples?

do you use(it have) in gradle build file both wrapper lib and physics lib?

for example:

compile "org.jmonkeyengine:jme3-bullet:$jmeVersion

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.

What about:
gradlew run

…note the ‘w’

Same error (and prequel message). This was with a “clean” before the “run,” just in case.

BTW, gradlew downloads a fairly old version of gradle (4.1, whereas my current system version is 5.6!)

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.

Yes, because as I recall some of our native build stuff only works with the older gradle… which is why it’s important to run with gradlew.

For example, last time I did gradle run in the jme directory it didn’t work for me either… but gradlew run does.

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?

Because the gradle builds work when we make releases?

2 Likes

complaining that it can’t find jni.h

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.

Have you tried run ANY OTHER JNI based app?

Fair enough. I was a bit frustrated when I wrote that. Back to trying to figure out why it’s not working for me

…on second thought, I think that the java build portions are working for me. Just, not the natives/connecting to the binaries to run examples.

1 Like

A possible workaround: edit jme3-examples/build.gradle to use JBullet instead of native Bullet:

    // EITHER use jme3-bullet + jme3-bullet-native OR ELSE jme3-jbullet
//    compile project(':jme3-bullet')
//    compile project(':jme3-bullet-native')
    compile project(':jme3-jbullet')

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 opened an issue at GitHub:
https://github.com/jMonkeyEngine/jmonkeyengine/issues/1208

@RiccardoBlb please investigate.

2 Likes

It should be fixed now. Pull the master and try

gradle build #this will download the prebuilt natives 
gradle run
3 Likes

Gradle or Gradlew or any?

It should work with both.

Thank you very much! I appreciate the response.

The downloaded natives seem to work fine now.

(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.

It’s usually not a good idea to develop opengl code with a virtual gpu. So, unless you can do gpu passthrough, you should probably avoid VMs.

1 Like