cc_import ignored by Objective-C linking logic

[keith]

If you have a cc_import that's depended on by a binary that goes through the apple_common.link_multi_arch_binary codepath, it appears that the necessary rpath is ignored, unlike when you link something with cc_common.link and one is added.

Here's a repro case dylibrepro.zip

The gist is that we have this setup:

load("@build_bazel_rules_apple//apple:macos.bzl", "macos_command_line_application")
load("@build_bazel_rules_swift//swift:swift.bzl", "swift_binary", "swift_library")

cc_import(
    name = "library",
    shared_library = "lib_InternalSwiftSyntaxParser.dylib",
)

swift_binary(
    name = "binary",
    srcs = ["main.swift"],
    linkopts = ["-l_InternalSwiftSyntaxParser"],
    deps = ["library"],
)

swift_library(
    name = "test_library",
    srcs = ["main.swift"],
    deps = ["library"],
)

macos_command_line_application(
    name = "macos_binary",
    linkopts = ["-l_InternalSwiftSyntaxParser"],
    minimum_os_version = "10.15",
    deps = ["test_library"],
)

Where the swift_binary rule goes through the cc_common.link API and the macos_command_line_application rule goes through the apple_common.link_multi_arch_binary API. If you run bazel run binary, it works correctly, and you can see the binary has the expected rpaths:

% otool -l bazel-bin/binary | grep RPATH -A2
          cmd LC_RPATH
      cmdsize 72
         path @loader_path/_solib_darwin_x86_64/_U_S_S_Clibrary___U (offset 12)
--
          cmd LC_RPATH
      cmdsize 32
         path /usr/lib/swift (offset 12)

If you run bazel run macos_binary, it crashes on launch because it's missing the expected library:

dyld: Library not loaded: @rpath/lib_InternalSwiftSyntaxParser.dylib
  Referenced from: /private/var/tmp/_bazel_ksmiley/94ddbbdef3cfe5ffbba16cb386c45110/execroot/__main__/bazel-out/applebin_macos-darwin_x86_64-fastbuild-ST-be99b7dfab2f/bin/macos_binary
  Reason: image not found

and you can see it has the load command but not the rpath:

% otool -L bazel-out/applebin_macos-darwin_x86_64-fastbuild-ST-be99b7dfab2f/bin/macos_binary
bazel-out/applebin_macos-darwin_x86_64-fastbuild-ST-be99b7dfab2f/bin/macos_binary:
        @rpath/lib_InternalSwiftSyntaxParser.dylib (compatibility version 1.0.0, current version 17013.0.0)
        /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 904.4.0)
        /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1770.255.0)
        /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.60.1)

% otool -l bazel-out/applebin_macos-darwin_x86_64-fastbuild-ST-be99b7dfab2f/bin/macos_binary | grep RPATH -A2
          cmd LC_RPATH
      cmdsize 32
         path /usr/lib/swift (offset 12)

In the case of Apple bundles, theoretically users can use a workaround such as the one in this PR to include the dylib as a framework instead, which will then be bundled with the executable, and by default have the right rpath, but this doesn't work for macos_command_line_application specifically since it isn't a bundle.

I believe the core issue here is that the Objective-C linking logic ignores CcInfo providers, there was some discussion on this here #11225 and there's a comment about it here https://github.com/bazelbuild/rules_swift/blob/618151af28d1aaf04612e75c142f4b48961d5012/swift/internal/compiling.bzl#L2585-L2588

So maybe this entire issue is just dependent on migrating entirely to the CcInfo API for Objective-C binaries.

[keith]

cc @googlewalt

[keith]

This might be related 2da8e84 to being able to pass a flag for this in starlark

[github-actions]

Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 1+ years. It will be closed in the next 14 days unless any other activity occurs or one of the following labels is added: "not stale", "awaiting-bazeler". Please reach out to the triage team (@bazelbuild/triage) if you think this issue is still relevant or you are interested in getting the issue resolved.

[keith]

I think this is generally solved by removing objc linking logic