New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Multiple swift_library transitions results in duplicate linkopts #1083
Comments
Not specific to swift, filed bazelbuild/bazel#19103 |
Would it be possible to move the dependency on the toolchain library to |
It wouldn't be since the top level binary might not be a swift_binary, it can also be an objc_library (with some magic linking), cc_binary, or anything else |
I feared that that might be the case. This is indeed tricky if you don't control the top-level rule. CC @gregestren, this is an interesting case where a "reset this dep to a certain top-level config" primitive would help. |
Can you clarify this comment? You mean Which flags did the transition change? |
Yes, the command line literally has:
Right, the configuration has to be different somehow, even if the difference isn't important to the
|
Any other bright ideas for this one? |
I'm not sure how the Swift logic sets and gets the linkopts info (the linkopts are set in a But going by bazelbuild/bazel#19103 (comment) - and making this about pure C++ - I'd hope that whatever C++ logic propagates up Toolchains intentionally take the target configuration because they could potentially generate libraries that link into the target binary: https://bazel.build/extending/toolchains#toolchains_and_configurations. So the fact you get two toolchain instances is by design. I'm not sure what a "revert to top-level config" scenario looks like in this case. Or if the C++ toolchain needs the target configuration as described in the last link. It's hard for me to think of an answer that isn't specific to C++ logic. |
i.e. "C++ linkopt logic intelligently deduplicates". |
@gregestren @fmeum
|
The duplication is happening because the C++ rules deduplicate the list of linkopts by reference, not by value, which does make sense since linker flags can cancel each other based on order. This is a tricky situation since it's entirely possible that a transition could affect the linkopts of the single unconfigured target. What should happen in that case? This sounds like the build graph equivalent of an ODR violation to me, so deduplication may end up masking situations that are straight up bugs. |
With this dependency graph:
Where
opt_wrapper
applies a transition tolib2
(aswift_library
) the result is there are 2 different@build bazel rules swift local config//:toolchain
targets with different transitions. Because of this the final linking action has duplicate info from these, such as-rpath /usr/lib/swift -rpath /usr/lib/swift
. In the past this hasn't been an issue, but with the new linker in Xcode 15 this produces a warning. Considering the options are the same, even though the configurations are different I'm surprised these aren't being de-duplicated somehow.This can be reproduced with this project on macOS: repro.zip using
bazel build main --linkopt=-v
and inspecting that the linker invocation has duplicate-rpath /usr/lib/swift
arguments. Or using Xcode 15 beta 5 you can pass--linkopt=-Wl,-fatal_warnings
and it will fail because of these duplicate arguments.The text was updated successfully, but these errors were encountered: