Undefined linker symbols related to indirect use of objc_library targets and cc_test

[chetgnegy]

Description of the problem / feature request:

I get linker errors (undefined symbols) when trying to indirectly test with gTest a c++ object that depends on an objc_library. Depending on the target directly, not using gTest, or excluding the Objective C details all work properly (but don't solve my specific problem).

Feature requests: what underlying problem are you trying to solve with this feature?

Build the Juce library on OSX (and test downstream targets), which uses Objective C libraries and involves a lot of complicated header configuration.
More info here:
https://github.com/chetgnegy/bazel_juce/blob/master/ThirdParty/Juce/juce.bzl

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Pull this repo:
https://github.com/chetgnegy/bazel_issue_9_4_2020

Verifies the issue is related to wrapped objc_libraries:
blaze clean && blaze run -c opt MinimalExample:MyLibBrokenTest # Linker error.
blaze clean && blaze run -c opt MinimalExample:MyLibWorkingBinary # Correctly outputs 42.
blaze clean && blaze run -c opt MinimalExample:MyLibWorkingTest. # Correctly outputs 42.
Substitute TARGET_UNDER_TEST in the BUILD file and run the commands again to verify that the issue is related to objc_library.

What operating system are you running Bazel on?

Catalina. This is my first time trying to build my codebase since getting a new machine. I'll note that I didn't have this issue on an older version of ~bazel 0.29.1 on OSX Mountain Lion, even though I know how useless that info might be. So it could have been introduced more recently. It could also depend on the gtest version. I no longer have that machine to do a side-by-side test.

What's the output of bazel info release?

release 3.5.0

though the issue exists as far back as 0.29.1

If bazel info release returns "development version" or "(@non-git)", tell us how you built Bazel.

bazel-3.5.0-installer-darwin-x86_64.sh

What's the output of git remote get-url origin ; git rev-parse master ; git rev-parse HEAD ?

https://github.com/chetgnegy/bazel_issue_9_4_2020.git
691f2dc9e4dfb4eeb7527d3cd0a7967350807e73
691f2dc9e4dfb4eeb7527d3cd0a7967350807e73

Have you found anything relevant by searching the web?

I haven't. This feels like a very specific issue.

Any other information, logs, or outputs that you want to share?

None. The repo should tell you everything I know.

[chetgnegy]

@calpeyser I know Cal isn't working on Bazel these days, but he helped out with a similar issue #3352 and might be able to give a kick in the right direction.

[chetgnegy]

Good news for anyone who might be helping me debug this: gtest was unrelated. It's actually the interaction between cc_test and transitive objc dependencies that causes the issue. If you simply make the dependency a cc_binary, everything works! I'm assuming there's a difference in how the two target types link? I'll update when I learn more.

This is more clear in my updated example:
chetgnegy/bazel_issue_9_4_2020@dfb9e59

[chetgnegy]

You can also view the diff in the verbose build commands between the cc_binary and an otherwise equivalent cc_test here:
https://www.diffchecker.com/oiBe1FsH

This version is a little clearer, it uses the same target name for both. It's much clearer what the difference is. The working cc_binary use static linkage and the non-working cc_test links a shared object.
https://www.diffchecker.com/GWZ5w5ra

[chetgnegy]

Alright. The next logical thing to do is to add linkstatic = 1 to the cc_library target "MyLib", and sure enough that fixes all my build problems!

I'll leave it to the experts to decide if this is a bug or working as intended.

[chetgnegy]

One more update. It turns out that it is necessary to link the library under test and not just the library that is directly including the objc_library. The library under test shouldn't be responsible for its dependencies' dependencies. To me that means we're in bug territory.

[sschaetz]

I am encountering that same problem with bazel 4.2.2 on macOS Monterey 12.1. The linkstatic = 1 work-around works well but as @chetgnegy mentioned it is quire awkward that a library has to do something specific to work with its dependencies' dependencies.

[keith]

Does this still repro with 5.x? I downloaded the most recent version of the repro case and things built correctly. If it does still repro can someone summarize the steps?

[sschaetz]

I just tried 5.0.0 and hit a different problem but that will be fixed with #14816. Once that is released will give it another try (or I figure out how to use a develop branch).

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