libtest/libstd being dynamically linked on macos

[snowp]

Presumably related to #1374

On the latest release we're still seeing rustlib being dynamically linked with a rust_binary output (non-trivial project setup, not sure how much this matters), resulting in a binary that cannot be loaded:

➜  sdk git:(main) ✗ otool -L bazel-bin/test/client/logger_runner

bazel-bin/test/client/logger_runner:
        @rpath/libtest-5266a2fa65112d20.dylib (compatibility version 0.0.0, current version 0.0.0)
        @rpath/libstd-f6811f31090e0239.dylib (compatibility version 0.0.0, current version 0.0.0)
...

We've been able to work through this by applying the following patch to rules_rust:

# https://github.com/bazelbuild/rules_rust/issues/1374

--- rust/private/repository_utils.bzl
+++ rust/private/repository_utils.bzl
@@ -33,6 +33,7 @@
             "lib/rustlib/{target_triple}/bin/rust-lld{binary_ext}",
             "lib/rustlib/{target_triple}/lib/*{dylib_ext}",
         ],
+        exclude = ["**/*libstd-*{dylib_ext}", "**/*libtest-*{dylib_ext}"],
         allow_empty = True,
     ),
     visibility = ["//visibility:public"],
@@ -149,6 +150,7 @@ def BUILD_for_clippy(target_triple):
             "lib/rustlib/{target_triple}/lib/*{staticlib_ext}",
             "lib/rustlib/{target_triple}/lib/self-contained/**",
         ],
+        exclude = ["**/*libstd-*{dylib_ext}", "**/*libtest-*{dylib_ext}"],
         # Some patterns (e.g. `lib/*.a`) don't match anything, see https://github.com/bazelbuild/rules_rust/pull/245
         allow_empty = True,
     ),

This unblocks us for now, but I'd love to understand how we can get this fixed for real. Would the approach we're taking here to just exclude the dylibs be a satisfactory solution?

@UebelAndre @scentini @keith

[gferon]

I'm also seeing the same issue with a rust_binary, I can try to make a small example project that fails to run on macOS.