-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
linker warnings on macOS XCode 14: ld: warning: -undefined dynamic_lookup may not work with chained fixups
#16413
Comments
As a temporary workaround you can pass |
This flag ignores undefined symbols at link time and forces them to be looked up dynamically. This is incompatible with the newer fixup chains macho format and theoretically shouldn't be necessary assuming your dependencies are well defined. Fixes bazelbuild#16413
This flag ignores undefined symbols at link time and forces them to be looked up dynamically. This is incompatible with the newer fixup chains macho format and theoretically shouldn't be necessary assuming your dependencies are well defined. Fixes bazelbuild#16413
From reading this, it seems like there are legitimate uses of this linker flag that don't have work-arounds. |
Yes there are definitely legit use cases, but I don't think it needs to be the default, since I believe most use cases are pretty specific scenarios |
With newer versions of macOS, LLVM and Bazel, a few things have changed and need to be accounted. - Chained fixups is a new feature that generates a warning when dynamic lookup is used for undefined symbols. Bazel's default local toolchain has now removed the dynamic lookups. See bazelbuild/bazel#16413 - Bazel 6.0.0 onwards have started using @loader_path; we need to update the wrapper script to handle these options accordingly. - Some basic test fixes for macOS M1 when an LLVM distribution is available, e.g. for LLVM version 15.0.0.
With newer versions of macOS, LLVM and Bazel, a few things have changed and need to be accounted. - Chained fixups is a new feature that generates a warning when dynamic lookup is used for undefined symbols. Bazel's default local toolchain has now removed the dynamic lookups. See bazelbuild/bazel#16413 - Bazel 6.0.0 onwards have started using @loader_path; we need to update the wrapper script to handle these options accordingly. - Some basic test fixes for macOS M1 when an LLVM distribution is available, e.g. for LLVM version 15.0.0.
With newer versions of macOS, LLVM and Bazel, a few things have changed and need to be accounted. - Chained fixups is a new feature that generates a warning when dynamic lookup is used for undefined symbols. Bazel's default local toolchain has now removed the dynamic lookups. See bazelbuild/bazel#16413 - Bazel 6.0.0 onwards have started using @loader_path; we need to update the wrapper script to handle these options accordingly. - Some basic test fixes for macOS M1 when an LLVM distribution is available, e.g. for LLVM version 15.0.0.
With newer versions of macOS, LLVM and Bazel, a few things have changed and need to be accounted. - Chained fixups is a new feature that generates a warning when dynamic lookup is used for undefined symbols. Bazel's default local toolchain has now removed the dynamic lookups. See bazelbuild/bazel#16413. However, the issue is a little more complex, so we keep it for now and document the ongoing resolution threads. - Bazel 6.0.0 onwards have started using @loader_path; we need to update the wrapper script to handle these options accordingly. - Some basic test fixes for macOS M1 when an LLVM distribution is available, e.g. for LLVM version 15.0.0.
With newer versions of macOS, LLVM and Bazel, a few things have changed and need to be accounted. - Chained fixups is a new feature that generates a warning when dynamic lookup is used for undefined symbols. Bazel's default local toolchain has now removed the dynamic lookups (see bazelbuild/bazel#16413). However, the issue is a little more complex, so we keep it for now and document the ongoing resolution threads between Apple and the community. - Bazel 6.0.0 onwards have started using @loader_path; we need to update the wrapper script to handle these options accordingly. - Some basic test fixes for macOS M1 when an LLVM distribution is available, e.g. for LLVM version 15.0.0.
This flag ignores undefined symbols at link time and forces them to be looked up dynamically. This is incompatible with the newer fixup chains macho format and theoretically shouldn't be necessary assuming your dependencies are well defined. Fixes #16413 Closes #16414. PiperOrigin-RevId: 501275674 Change-Id: I9240b2596ffea329ef55d3ad15e98635ba8839b6
With newer versions of macOS, LLVM and Bazel, a few things have changed and need to be accounted. - Chained fixups is a new feature that generates a warning when dynamic lookup is used for undefined symbols. Bazel's default local toolchain has now removed the dynamic lookups (see bazelbuild/bazel#16413). However, the issue is a little more complex, so we keep it for now and document the ongoing resolution threads between Apple and the community. - Bazel 6.0.0 onwards have started using @loader_path; we need to update the wrapper script to handle these options accordingly. - Some basic test fixes for macOS M1 when an LLVM distribution is available, e.g. for LLVM version 15.0.0.
Description of the problem / feature request:
cc_binary
built on MacOS with XCode 14 results in warnings link the following being printed:ld: warning: -undefined dynamic_lookup may not work with chained fixups
Maybe due to this?
bazel/tools/osx/crosstool/cc_toolchain_config.bzl
Line 1130 in 32d56b6
Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
git clone https://github.com/bazelbuild/examples cd examples/cpp-tutorial/stage3 bazel build //...
Output:
What operating system are you running Bazel on?
MacOS 12.6
What's the output of
bazel info release
?release 5.3.1
What version of rules_cc do you use? Can you paste the workspace rule used to fetch rules_cc? What other relevant dependencies does your project have?
built in, but also tried
0.0.4
What Bazel options do you use to trigger the issue? What C++ toolchain do you use?
Didn't specify any bazel options or configure any custom toolchain.
Have you found anything relevant by searching the web?
python/cpython#97524
ruby/ruby#6193
https://issues.guix.gnu.org/issue/57849
The text was updated successfully, but these errors were encountered: