src/main/tools/process-wrapper-legacy.cc:80: "execvp(external/rules_java++toolchains+remote_java_tools_linux/java_tools/turbine_direct_graal, ...)": No such file or directory

https://github.com/bazel-contrib/rules_jvm_external/issues/1451 follow-up,

but this time in the right project repo (hopefully) - if I understand correctly?

In https://github.com/enola-dev/enola/issues/1730#issuecomment-3390839018,

where I'm having (too much...) fun with running a Bazel Java build inside a reproducible [Nix](https://nixos.org) package "derivation" build,

when running `nix run .` on https://github.com/enola-dev/enola/pull/1873/files, the @dotdoom and me are running into:

`ERROR: /build/home/.cache/bazel/_bazel_nixbld/c122cde4e9cdfc8e96d0ecdf2a867384/external/rules_jvm_external+/private/tools/java/com/github/bazelbuild/rules_jvm_external/BUILD:3:13: Compiling Java headers external/rules_jvm_external+/private/tools/java/com/github/bazelbuild/rules_jvm_external/librules_jvm_external-hjar.jar (3 source files) [for tool] failed: (Exit 1): turbine_direct_graal failed: error executing Turbine command (from target @@rules_jvm_external+//private/tools/java/com/github/bazelbuild/rules_jvm_external:rules_jvm_external) external/rules_java++toolchains+remote_java_tools_linux/java_tools/turbine_direct_graal '-Dturbine.ctSymPath=external/rules_java++toolchains+local_jdk/lib/ct.sym' --output ... (remaining 30 arguments skipped)`

`Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
src/main/tools/process-wrapper-legacy.cc:80: "execvp(external/rules_java++toolchains+remote_java_tools_linux/java_tools/turbine_direct_graal, ...)": No such file or directory`

Do you have any suggestions on what could be causing this, and how to fix it?

Note that this [Nix](https://nixos.org) package "derivation" build is a restricted sandbox, with a controlled PATH,

within which we run `bazel build --vendor_dir=...`

I'm struggling to fully grasp what the error message above is trying to tell us.

Surely, whatever exactly that `turbine_direct_graal` binary is "available"? It's presumably something from `rules_java`, right?

That _"No such file or directory"_ more likely means... like, what? It's perhaps missing a dynamically linked library that it depends on? That may well be missing in that restrictive Nix sandbox environment. Wouldn't it be simpler to make that binary statically linked? (If this is even the root cause; I'm a little bit out of my depth here.)

@meteorcloudy @cushon @fmeum perhaps you have thoughts about this.

Start at src/main/tools/process-wrapper-legacy.cc:80 and reproduce the failure with the reported bazel build --vendor_dir=... command inside the restricted Nix derivation sandbox. Use --sandbox_debug to inspect the retained build root and determine why turbine_direct_graal cannot be executed. Done means documenting the root cause and an appropriate fix for this environment.

Vom Indexierungsmodell aus dem Issue-Text verfasst.