Enable @examples//ffi/rust_calling_c/... on MacOS CI

[UebelAndre]

Building these targets generates a build failure

rust_calling_c % bazel build ...

INFO: Invocation ID: f981af43-943e-40bb-ba01-ed9362446315
INFO: Analyzed 15 targets (0 packages loaded, 0 targets configured).
INFO: Found 15 targets...
ERROR: /private/var/tmp/_bazel_user/1426ad6c00f8f7b996ddc75bef70871c/external/local_libstdcpp/BUILD.bazel:3:11: SolibSymlink _solib_darwin_x86_64/_U@local_Ulibstdcpp_S_S_Clibstdc++___U/libstdc++.6.dylib failed: missing input file 'external/local_libstdcpp/libstdc++.6.dylib', owner: '@local_libstdcpp//:libstdc++.6.dylib'
ERROR: /private/var/tmp/_bazel_user/1426ad6c00f8f7b996ddc75bef70871c/external/local_libstdcpp/BUILD.bazel:3:11 SolibSymlink _solib_darwin_x86_64/_U@local_Ulibstdcpp_S_S_Clibstdc++___U/libstdc++.6.dylib failed: 1 input file(s) do not exist
INFO: Elapsed time: 0.415s, Critical Path: 0.01s
INFO: 11 processes: 11 internal.
FAILED: Build did NOT complete successfully

The examples should be updated (or potentially the underlying rust_bindgen rules) to support MacOS.

[csmulhern]

One issue here (other than the local_libstdcpp issue above) is that no install name is used by bazel when compiling dynamic libraries on macOS. This results in binaries produced by rust_* using relative search paths for dynamic libraries, which are not appropriate for the produced binary. The cc actions take the additional step of patching up their binaries using install_name_tool to work around this (see: https://cs.opensource.google/bazel/bazel/+/master:tools/cpp/osx_cc_wrapper.sh). A new flag has been added to bazel that will fix this behavior: --incompatible_macos_set_install_name. It is currently broken, but will be fixed by bazelbuild/bazel#13427.

Once that lands, _compute_rpaths will need to be updated here: https://github.com/bazelbuild/rules_rust/blob/main/rust/private/rustc.bzl#L715. This method should be updated to use the simpler _is_dylib condition for selecting dylib artifacts, as called out by augie, as .so is used for dynamic libraries in place of dylib on macOS often (and in the rust_calling_c examples specifically). In addition, the toolchain check should be updated to not fail when the OS is darwin.

[djmarcin]

My rust_bindgen rule fails with the originally cited error on macOS, so it sounds like the rpath/install_name issue is potentially a separate issue from the above error to me.

[djmarcin]

It looks like #741 covers the rust_bindgen problem more specifically.