java.library.path not being set correctly

[seanmcl]

https://github.com/seanmcl/scala-bazel-bug-linker

demonstrates a bug that shows java.library.path is not set correctly.

I haven't found a workaround for this. No combination of DYLD_LIBRARY_PATH, --test_env, --action_env, --jvmargs lets me set the path, even if I hard code the mangled solib path.

[johnynek]

Thanks for this report. Can you make a PR with a failing test (for instance something to uses a library from scala but it fails due to this?)

I guess the correct approach is see if any of the deps are cc_library instances and if so, get the directory that has the files and add that.

[seanmcl]

Will do. I haven't dug into the java_library rule at all, so I'm not sure that step is sufficient for all cases, but being able to add native libraries in this way would be a good first step. If I can figure out how to do it myself I'll send a PR.

[johnynek]

It is entirely possible we need more bazel features to do this. I am not sure how much of a skylark (the extension language) API that the C++ rules expose. We may be okay, but if not, we should get some figure that out and get some bug reports filed with bazel.

The java rules are not (currently) implemented with skylark, so the fact that they can do it is not proof it would be easy to do it with skylark.

[seanmcl]

I'm puzzled. If I use a precompiled 'foo.dylib' file (OSX) than the java_library rule sets the path correctly. However, if I compile a C file using cc_library, the resulting file is 'foo.so' and is neither loadable directly (I need to change the name to foo.dylib) nor does it end up on the java.library.path. I'd prefer to not check in an architecture-specific file for the tests, and now I don't understand how mixed Java/C libraries work at all in bazel. Will make a PR with this info.

[johnynek]

@seanmcl this sounds like a bazel bug. I'd mail the list or file an issue (or both).

[seanmcl]

Submitted: #140

[lgirault]

So I have a similar issue an UnsatisfiedLinkError link errors that complains that the so is not in java.library.path. Upon further investigation, java.library.path seems correctly set, but its entries are relative path refering to the parent folder e.g: ../mylib.jar.

It seems like there is an issue with regards to the sandboxing. To debug I added ls .. here. When running bazel test mytest, I got the following entries :

bazel_tools
my_lib
io_bazel_rules_scala
io_bazel_rules_scala_scala_library
io_bazel_rules_scala_scala_reflect
io_bazel_rules_scala_scala_xml
io_bazel_rules_scala_scalactic
io_bazel_rules_scala_scalatest
jni_scala_test
local_jdk

But when I run the command obtained with bazel test mytest -s, I also have a MANIFEST file which the correct location of all the jars. The same MANIFEST referenced by the RUNFILES_MANIFEST_FILE variable. I'm not sure how the sandbox is setup. If I could have some hints on where to look, it would be much appreciated.