Lots of linkopts brokenness between cc and objc rules

[cpsauer]

Hi wonderful Bazel folks,

Category:

This is a cc & objc rules interoperability issue, wherein linkopts get dropped in multiple ways.

Severity:

In the real world, I'd expect this to cause problems in a codebase of any reasonable size that tries to use the cc <-> objc interoperability Bazel tries to support, since, eventually, you'll try to link to a system library (like libz) and get hosed. At least so far, I don't see a good workaround, besides misapplying all the linker settings at the root, rather breaking the niceness of the idea of a build graph.

Demo:

For easy debugging, I've cooked up a simple little example that I think shows at least two sub-issues:

1. linkopts get dropped when a cc_library depends on an objc_library
2. linkopts get dropped when an objc_library depends on a cc_library

In the example, the interesting part is the BUILD file. A -> B -> C

cc_binary(
    name = "A",
    srcs = ["A.c"],
    deps = [":B"],
)

objc_library(
    name = "B",
    deps = [":C"],
    linkopts = ["-shouldCauseLinkerError1"],
)

cc_library(
    name = "C",
    linkopts = ["-shouldCauseLinkerError2"],
)

If linker errors were getting propagated properly, bazel build :A would fail, complaining about unknown arguments -shouldCauseLinkerError1 and -shouldCauseLinkerError2 but instead both get dropped, and the build succeeds. Wat.

[You can sanity check the right behavior by adding a direct dependency from A -> C, and bingo: clang: error: unknown argument: '-shouldCauseLinkerError2'. Inconsistent. Sad times.]

Here's a zip of the example workspace for your debugging (dis?)pleasure. Definitely makes my Bazel-loving, ex-Googler heart sad.
LinkoptsBreakageExample.zip

More context:

I suspect #13205 is related, and maybe just a consequence of this.

And I think I should be starting by tagging @googlewalt and @oquenchil, because it looks related to things where I'd interacted with them before, like #10674. (Please tell me if that's wrong.)

Also, if anyone knows where in Bazel core's source this bug would be, please lmk! I'd started looking into it, but saw was getting both starlark and java source coming up in my search, so I figured I'd better check in first. Plus, I've got a pretty big stack of Bazel PRs outstanding already.

Thanks so much for looking into it,
Chris
(ex-Googler)

[keith]

Related bazelbuild/rules_swift#432

[cpsauer]

heh, Keith with the blazingly fast crossref, as always :)

[googlewalt]

I have a detailed internal document to migrate ObjcProvider link info to CcLinkingContext, which should address this bug. I expect to get back to that project shortly, and one of my first tasks will be to make a public version of that doc. I'll update this issue when that becomes available.

[cpsauer]

Wow! Thank you, Walter! Excited to see.

[cpsauer]

I noticed some recent improvement in this general area!
Seems like cc -> objc now works for sdk_dylibs, if not for the general linker flags in the example above. That is, adding

sdk_dylibs = ["libdoesntexist"],

to :B, the objc_library, above, now correctly gives ld: library not found for -ldoesntexist, as of Bazel rolling's 6.0.0-pre.20220331.1 but not 6.0.0-pre.20220328.1

@warriorstar-orion, could you confirm that that's solves your problem in #13205? (Note that apple_binary has been removed, so you'll have to update your minimal example a bit.)

Have you been working your magic, @googlewalt? :)

[googlewalt]

It wasn't me directly, but we did make this incremental improvement: 203f2c5.

[warriorstar-orion]

@cpsauer oh man it's been a minute since i've looked at the project that surfaced to me. Let me get back to you on that.

[keith]

I think some of these cases are fixed now

[cpsauer]

Just pulled down the minimal example and both get propagated with the latest rolling (8.0.0-pre.20231030.2). Yay! The build graph abstraction is back usable here.

Keith, are there more cases you think are still outstanding, or shall we close this down?

(Anyone else trying, you have to add bazel_dep(name = "apple_support", version = "1.11.1", repo_name = "build_bazel_apple_support") to MODULE.bazel)

[keith]

I'm not tracking any at this point but it's possible I'm just working around them and have forgotten them, lets close and reopen new ones if they come up

[cpsauer]

Sounds like a plan, Keith. Thanks all for all the work you've done and are doing to improve these things. Please know that I so, so appreciate you guys.

[cpsauer]

(If anyone knows of other, broader issues/plans I should track around this stuff to be informed, please lmk. Keith, I really appreciate also your circling back to close this, so I knew that a bunch of workarounds could be unwound.)