objc_library sdk_dylibs not propagated to cc_binary rules, only apple_binary rules

[warriorstar-orion]

Description of the problem / feature request:

I'm no C++ or linking expert so I have no idea if this should work or not, but I believe it should. The documentation for objc_library.sdk_dylibs states:

When linking a binary, all libraries named in that binary's transitive dependency graph are used.

However, this is only the case for apple_binary rules, not cc_binary rules. The repo https://github.com/warriorstar-orion/bazel_objc_dylibs is a bare minimum demonstration and should allow you to reproduce the issue.

A sample run:

% clang -v
Apple clang version 12.0.0 (clang-1200.0.32.28)
Target: x86_64-apple-darwin20.3.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
% xcrun --show-sdk-path
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk
% xcrun --show-sdk-version
11.1

% bazel build :thing_apple_binary
INFO: Analyzed target //:thing_apple_binary (0 packages loaded, 0 targets configured).
INFO: Found 1 target...
Target //:thing_apple_binary up-to-date:
  bazel-out/apl-darwin_x86_64-fastbuild/bin/thing_apple_binary_lipobin
INFO: Elapsed time: 0.136s, Critical Path: 0.00s
INFO: 1 process: 1 internal.
INFO: Build completed successfully, 1 total action

% bazel build :thing_cc_binary
INFO: Analyzed target //:thing_cc_binary (0 packages loaded, 0 targets configured).
INFO: Found 1 target...
ERROR: /Users/orion/ExternalRepos/bazel_objc_dylibs/BUILD.bazel:15:10: Linking thing_cc_binary failed: (Exit 1): cc_wrapper.sh failed: error executing command external/local_config_cc/cc_wrapper.sh @bazel-out/darwin-fastbuild/bin/thing_cc_binary-2.params

Use --sandbox_debug to see verbose messages from the sandbox cc_wrapper.sh failed: error executing command external/local_config_cc/cc_wrapper.sh @bazel-out/darwin-fastbuild/bin/thing_cc_binary-2.params

Use --sandbox_debug to see verbose messages from the sandbox
Undefined symbols for architecture x86_64:
  "_iconv", referenced from:
      _main in liblibthing.a(main.o)
  "_iconv_close", referenced from:
      _main in liblibthing.a(main.o)
  "_iconv_open", referenced from:
      _main in liblibthing.a(main.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Target //:thing_cc_binary failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 0.239s, Critical Path: 0.10s
INFO: 2 processes: 2 internal.
FAILED: Build did NOT complete successfully
%

bazel aquery confirms the lack of an added linker option:

% bazel aquery :thing_apple_binary 2> /dev/null | grep -i iconv
    -liconv \
% bazel aquery :thing_cc_binary 2> /dev/null | grep -i iconv
%

What operating system are you running Bazel on?

% uname -a
Darwin ophelia.local 20.3.0 Darwin Kernel Version 20.3.0: Thu Jan 21 00:07:06 PST 2021; root:xnu-7195.81.3~1/RELEASE_X86_64 x86_64
% sw_vers -productVersion
11.2

What's the output of bazel info release?

release 4.0.0-homebrew

Have you found anything relevant by searching the web?

Nothing stands out

[warriorstar-orion]

I should add the practical effect of this is that if an objc_library which uses sdk_dylibs is far down the dependency chain, a cc_binary won't properly link everything unless it itself has a e.g. linkopts = ["-liconv"], which is very spooky-action-at-a-distance, and also pushes logic about platform-specific attributes in a place where the given library may have already (and most likely if a library is multi-platform) taken care of.

[cpsauer]

Just ran into this one, too. Heads that there seems to be a much more general problem with linkopt interoperability here, so I filed #10738

[cpsauer]

Note, this issue seems likely fixed in the latest bazel rolling release. See #15014 (comment)

[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.

[github-actions]

This issue has been automatically closed due to inactivity. If you're still interested in pursuing this, please reach out to the triage team (@bazelbuild/triage). Thanks!

[keith]

I agree this is probably fixed but I haven't tested either