As described in symlink_helpers.bzl, copied here for visibility:
Symlinking busybox things needs special logic.
This is because Bazel doesn't cache the actual symlink, resulting in essentially resolved symlinks being produced in place of the expected tool. As a consequence, we can't rely on the symlink name when dealing with busybox entries.
An example repro of this using a local build cache is:
We could in theory get reasonable behavior with ctx.actions.declare_symlink, but that's disallowed in our .bazelrc for cross-environment compatibility.
The particular approach here uses the Python script as a launching pad so that the busybox still receives an appropriate location in argv[0], allowing it to find other files in the lib directory. Arguments are inserted to get equivalent behavior as if symlink resolution had occurred.
As described in symlink_helpers.bzl, copied here for visibility:
Symlinking busybox things needs special logic.
This is because Bazel doesn't cache the actual symlink, resulting in essentially resolved symlinks being produced in place of the expected tool. As a consequence, we can't rely on the symlink name when dealing with busybox entries.
An example repro of this using a local build cache is:
We could in theory get reasonable behavior with
ctx.actions.declare_symlink, but that's disallowed in our.bazelrcfor cross-environment compatibility.The particular approach here uses the Python script as a launching pad so that the busybox still receives an appropriate location in argv[0], allowing it to find other files in the lib directory. Arguments are inserted to get equivalent behavior as if symlink resolution had occurred.
The underlying bug is noted at: https://github.com/bazelbuild/bazel/issues/23620