BREAKING: Modify path layout to fix relative RPATH lookups

[fmeum]

The executable of an executable transitioned rule is now created in a subdirectory of the target's package, which allows it to match the path depth under the execroot of the original executable and thus gets relative RPATH entries to resolve.

Also copy any DLLs next to the new executable on Windows.

The new path layout can be disabled via --no@with_cfg.bzl//:incompatible_same_depth_path_layout, e.g. if users hardcoded rlocationpaths and don't want to update them now. It is recommended to avoid this and use $(rlocationpath ...) instead.

Fixes #85

[fmeum]

@keith This PR should fix the problems with shared deps on Linux, but it runs into a surprising failure on macOS: Despite a matching LC_RPATH entry at https://github.com/fmeum/with_cfg.bzl/actions/runs/10075507430/job/27853944169?pr=104#step:5:356, the test fails and (seemingly) never searches in that location. Do you have an idea why?

[fmeum]

I can reproduce this failure on test_cc_binary_tool_with_dynamic_deps in Bazel (see bazelbuild/bazel#23085, in which I enable more tests on macOS). I'm confused by what I'm seeing: Why doesn't Bazel set @rpath/libname.dylib as LC_LOAD_DYLIB and then adds appropriate LC_RPATH entries (usually multiple) as on Linux? As it stands, it looks like the LC_RPATH entries are simply ignored.

[fmeum]

Can confirm that this patch to Bazel fixes the problem:

diff --git a/tools/cpp/osx_cc_wrapper.sh.tpl b/tools/cpp/osx_cc_wrapper.sh.tpl
index e40a98bb1a601d..3d5e3bdfb3beed 100644
--- a/tools/cpp/osx_cc_wrapper.sh.tpl
+++ b/tools/cpp/osx_cc_wrapper.sh.tpl
@@ -106,7 +106,7 @@ function get_otool_path() {
 
 function call_install_name() {
     /usr/bin/xcrun install_name_tool -change $(get_otool_path "$1") \
-        "@loader_path/$2/$3" "${OUTPUT}"
+        "@rpath/$3" "${OUTPUT}"
 }
 
 # Do replacements in the output

[fmeum]

Sorry for the stream of messages here, I just now learned about --incompatible_macos_set_install_name. Looks like flipping that is required for correct dylib discovery, but the issue about it has gone stale (bazelbuild/bazel#12370)? Do you see a reason not to flip this?

[fmeum]

TLDR is that this is broken in Bazel without bazelbuild/bazel#23089. I disabled the test on macOS for now.