--incompatible_strict_action_env breaks msan builds

[iphydf]

This is a reproducing Dockerfile:

FROM l.gcr.io/google/bazel:3.0.0

WORKDIR /src
RUN ["git", "clone", "--depth=1", "https://github.com/abseil/abseil-cpp.git", "/src"]
RUN ["bazel", "test", "--config=msan", "//absl/strings:string_view_test", \
        "--test_output=errors"]
RUN ["bazel", "test", "--config=msan", "//absl/strings:string_view_test", \
        "--test_output=errors", "--incompatible_strict_action_env"]

The first bazel test works, the second one fails with

==================== Test output for //absl/strings:string_view_test:
/root/.cache/bazel/_bazel_root/f8087e59fd95af1ae29e8fcb7ff1a3dc/sandbox/processwrapper-sandbox/55/execroot/com_google_absl/bazel-out/k8-fastbuild/bin/absl/strings/string_view_test.runfiles/com_google_absl/absl/strings/string_view_test:\
 error while loading shared libraries: libc++.so.1: cannot open shared object file:\
 No such file or directory
================================================================================

Also see bazelbuild/bazel#7026, not sure it's relevant, but it's about the same strict action env flag.

Why this is important: while this is a simple repro, and you may say "just don't use that flag", the same problem occurs when running without that flag and using a rule with a tool built in the same bazel build.

[smukherj1]

Is this something specific to the Bazel container or can it be reproduced just with Bazel 3.0?

Also, to debug I would suggest examining the LD_LIBRARY_PATH environment variables between the actions which work vs which don't when running executables built using the --config=msan flag. This is most likely a case of LD_LIBRARY_PATH not including the directory with the msan flavor of libc++ when running the action that's trying to use a binary built using --config=msan.

[iphydf]

It can be reproduced with docker-sandbox, I think. Thanks for the pointer to LD_LIBRARY_PATH. I considered adding that, and I think at one point I tried and got segfaults or missing symbols, so I stopped going along that path, but I'll investigate it a bit more.