-
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
Remove use of -undefined dynamic_lookup on darwin #16414
Remove use of -undefined dynamic_lookup on darwin #16414
Conversation
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
65bc2a9
to
f0b850f
Compare
The second commit here shows a potential issue making this change could introduce, that library had incorrect dependencies but just happened to work at runtime because the library it needed must have been transitively loaded anyways. I also found this #7607 |
@oquenchil can you take a look? |
@bazel-io flag |
for future reference there were some previous additions / removals of this too: #67 |
This looks like a breaking change:
Detected by culprit finder: https://buildkite.com/bazel/culprit-finder/builds/4178#0185a952-34c1-46ae-99c8-9b40d67508ec |
Since this is likely a breaking change, I'll remove the "potential release blocker" label. |
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
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. Done in bazel's toolchain here bazelbuild/bazel#16414
@keith Is googletest doing something wrong? git clone [email protected]:google/googletest.git
cd googletest Before this change: USE_BAZEL_VERSION=7.0.0-pre.20221212.2 bazelisk test --java_runtime_version=remotejdk_11 --copt='-std=c++14' //googletest/test:gtest_all_test Succeeds After this change: USE_BAZEL_VERSION=7.0.0-pre.20230118.2 bazelisk test --java_runtime_version=remotejdk_11 --copt='-std=c++14' //googletest/test:gtest_all_test
ERROR: /Users/garymm/src/google/googletest/BUILD.bazel:152:11: Linking libgtest_main.dylib failed: (Exit 1): cc_wrapper.sh failed: error executing command (from target //:gtest_main) external/local_config_cc/cc_wrapper.sh @bazel-out/darwin_arm64-fastbuild/bin/libgtest_main.dylib-2.params
Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
Undefined symbols for architecture arm64:
"testing::InitGoogleMock(int*, char**)", referenced from:
_main in gmock_main.pic.o
"testing::UnitTest::GetInstance()", referenced from:
RUN_ALL_TESTS() in gmock_main.pic.o
"testing::UnitTest::Run()", referenced from:
RUN_ALL_TESTS() in gmock_main.pic.o
ld: symbol(s) not found for architecture arm64 |
This feature isn't supported on macOS, and it isn't part of the Xcode CC toolchain, but it is left over here from when it was supported in the past. bazelbuild@ec55533 Fixes: bazelbuild#16414 (comment)
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. Done in bazel's toolchain here bazelbuild/bazel#16414
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. Done in bazel's toolchain here bazelbuild/bazel#16414
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