Dynamic linking failure (at runtime) with cbits dependency

[iphydf]

https://travis-ci.org/iphydf/repro140/jobs/344336314#L740

==================== Test output for @haskell_dlist//:test:
/home/travis/.cache/bazel/_bazel_travis/62cd4b4156760703e80e26252af7b00f/bazel-sandbox/1857824427084396710/execroot/repro140/bazel-out/k8-fastbuild/bin/external/haskell_dlist/test.runfiles/repro140/external/haskell_dlist/test: error while loading shared libraries: bazel-out/k8-fastbuild/bin/external/haskell_tf_random/libexternal_Shaskell_Utf_Urandom_Scbits_libcbits.so: cannot open shared object file: No such file or directory

[iphydf]

Extra info: if I make the cbits library linkstatic = 1, I get a link time error about missing a symbol from that library (Threefish_256_Process_Block).

[mrkkrp]

I was able to reproduce it. For this to work we need to run the test executable in a modified environment setting LD_LIBRARY_PATH perhaps. I'm currently reading the docs and I don't see how this can be done.

Another difficulty is that although we know location of dynamic libraries when we link the executable, I don't see how to pass that information to whatever is in charge of running the test. Test rule should produce only ctx.outputs.executable.

It is not obvious to me how to make it work. Doesn't mean there isn't a way to do that, though.

@mboes Looks like the broken distribution story hits us even in just running the tests.

[mrkkrp]

One particularly perverted way to make it work would be via outputting a shell script instead of executable (still need to link an executable first, of course) when we're generating a test (test = True). In that shell script we would need to set environment variables and then call the executable.

[iphydf]

Generating shell scripts seems to be quite a common way for bazel rules. Java test binaries are shell scripts, as well.

[mboes]

Elevating priority level.

[mboes]

Generating scripts might well be the way forward. Before we do that though, is there any chance we could do away with setting LD_LIBRARY_PATH? If we didn't need that env var, that would solve the issue too, right?

[mrkkrp]

I worked on this today, actually, and I have found out what works and what does not. It's 2 am here however and I'll share my findings tomorrow. Hopefully, I should also get it to work tomorrow.