Fix protoc_nowkt linking on MacOS #12320
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
zhangskz
added
the
🅰️ safe for tests
github-actions
bot
removed
the
🅰️ safe for tests
JasonLunn
added
c++
🅰️ safe for tests
github-actions
bot
removed
the
🅰️ safe for tests
|
Thanks for this patch! Sorry for the late response, can you sync to main so I can rerun tests and get it in? |
Depending on how the local cc toolchain is setup on macos, the core foundation framework might not be available while linking protoc_nowkt. This results in a few _CF symbols being interpreted as dynamic load and is set to the binary's flat-namespace, causing runtime errors during susequent actions such as gen_wkt_cc_sources. ```bash > otool -dyld_info bazel-out/darwin_arm64-opt-exec-2B5CBBC6/bin/external/com_google_protobuf/src/google/protobuf/compiler/protoc_nowkt | grep '_CF' __DATA_CONST __got 0x10035C038 0x8010000000000007 bind 0x0 flat-namespace _CFRelease __DATA_CONST __got 0x10035C040 0x8010000000000008 bind 0x0 flat-namespace _CFStringGetCString __DATA_CONST __got 0x10035C048 0x8010000000000009 bind 0x0 flat-namespace _CFStringGetLength __DATA_CONST __got 0x10035C050 0x801000000000000A bind 0x0 flat-namespace _CFStringGetMaximumSizeForEncoding __DATA_CONST __got 0x10035C058 0x801000000000000B bind 0x0 flat-namespace _CFTimeZoneCopyDefault __DATA_CONST __got 0x10035C060 0x801000000000000C bind 0x0 flat-namespace _CFTimeZoneGetName ``` Tell the linker to use CoreFoundation framework explicitly fixes this issue. ```bash > otool -dyld_info bazel-out/darwin_arm64-opt-exec-2B5CBBC6/bin/external/com_google_protobuf/src/google/protobuf/compiler/protoc_nowkt | grep '_CF' __DATA_CONST __got 0x10035C038 0x8010000000000007 bind 0x0 CoreFoundation _CFRelease __DATA_CONST __got 0x10035C040 0x8010000000000008 bind 0x0 CoreFoundation _CFStringGetCString __DATA_CONST __got 0x10035C048 0x8010000000000009 bind 0x0 CoreFoundation _CFStringGetLength __DATA_CONST __got 0x10035C050 0x801000000000000A bind 0x0 CoreFoundation _CFStringGetMaximumSizeForEncoding __DATA_CONST __got 0x10035C058 0x801000000000000B bind 0x0 CoreFoundation _CFTimeZoneCopyDefault __DATA_CONST __got 0x10035C060 0x801000000000000C bind 0x0 CoreFoundation _CFTimeZoneGetName ``` closes #12173
|
@deannagarcia I don't think there is any conflict, but I rebased anyway. |
deannagarcia
added
the
🅰️ safe for tests
github-actions
bot
removed
the
🅰️ safe for tests
deannagarcia
approved these changes
Apr 24, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Depending on how the local cc toolchain is setup on macos, the core
foundation framework might not be available while linking protoc_nowkt.
This results in a few _CF symbols being interpreted as dynamic load and
is set to the binary's flat-namespace, causing runtime errors during
susequent actions such as gen_wkt_cc_sources.
Tell the linker to use CoreFoundation framework explicitly fixes this
issue.
closes #12173