New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
no bulletjme in java.library.path #1208
Comments
See commit b571840. I will test it soon. |
I tested d8a42d0 and encountered a new issue:
|
I'm testing on a clean clone and i can't reproduce the issue... But it's part of the migration code that will be removed anyway, now that we have a fresh snapshot with the new paths. |
Can you test it now and confirm that everything works? I'm also adding here a quick summary of what was causing the error and what the fix is about: The build script used to have custom logic to add the natives inside the release jar, it seems that having them in the classpath during the debug was a biproduct of this process (since they weren't specifically added as dependency in the buildscript) when i moved the native binaries outside the repo, this changed and didn't work anymore. The fix i adopted is to remove all the custom logic and include the natives as resources, in doing this i had to change the paths in the snapshot archive to make them match the expected paths in the jar. |
I tested a fresh clone of 3217cdc and got back to the original issue:
|
I see, i was under the wrong assumption that zipTree was going to return unix style paths. |
I will try that. |
The replacement you suggested seems to resolve this issue. |
@stephengold the getPrebuiltNatives failing issue I have encountered twice now (over about 50 builds) in the last week. I do not have a way to replicate it, but for some reason it does occur. |
@riccardobl shall I commit the change, or will you? |
Done d018666 |
@tlf30 since the failures you saw were not consistent, I wonder if they might be due to network issues. |
@stephengold that is very likely. |
I'm seeing this issue in current |
This is #1260, the native libraries aren't added when the run task is run. This is related to the following: Actually now that I re-think of #1260, we should just update the PR and make the run task just also depend on the natives task. Simple fix. Also we should add |
sailsman63 reported this issue at the Forum: when TestChooser is run from the command line using
gradlew run
, the bulletjme native library isn't loaded.I downloaded and unzipped the native snapshot from https://dl.bintray.com/jmonkeyengine/files/a4c694ba36258af5c6ce7823f4bdacc424988557/jme3-natives.zip
It looks like the bulletjme native library for my platform is in
bullet/windows/x86_64/bulletjme.dll
, but the loader is looking fornative/windows/x86_64/bulletjme.dll
.The text was updated successfully, but these errors were encountered: