-
Notifications
You must be signed in to change notification settings - Fork 22
Hide all ICU public C++ Symbols #34
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we also revert #19 as part of this change?
I didn't bother because we are gonna upgrade ICU very soon anyways. We just won't apply that diff anymore |
528ad42
to
85d92d8
Compare
Added comments. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left two small nits on the wording in the comment that I think might help clarify what we found in our investigation, but otherwise this looks good to me thanks!
Should we run a full toolchain build before merging to ensure we don't break the toolchain with this change just in case something goes wrong?
**Rationale:** When FoundationInternationalization tests are executed, we effectively load two ICU instances into memory: 1) The system ICU loaded by XCTest via system Foundation; 2) The package ICU SwiftFoundation utilizes. These two ICUs cause symbol collisions for dyld due to the fact that all public C++ symbols share a global namespace and coalesce across all loaded dylibs. Consequently, we encounter sporadic test failures in SwiftFoundation as dyld arbitrarily selects ICU symbols and occasionally chooses the system one. To address this issue, we resolved to hide all C++ APIs, ensuring they are not weakly referenced and potentially bound to the system ICU implementation. This solution proves effective for SwiftFoundation, as it does not actually utilize the C++ APIs.
85d92d8
to
ff7d419
Compare
Toolchain build test: swiftlang/swift#75452 |
Looks like this caused toolchain build failures that we'll need to resolve:
|
Building new toolchain now... |
Rationale: When FoundationInternationalization tests are executed, we effectively load two ICU instances into memory: 1) The system ICU loaded by XCTest via system Foundation; 2) The package ICU SwiftFoundation utilizes.
These two ICUs cause symbol collisions for dyld due to the fact that all public C++ symbols have their own namespaces and coalesce across all loaded dylibs. Consequently, we encounter sporadic test failures in SwiftFoundation as dyld arbitrarily selects ICU symbols and occasionally chooses the system one.
To address this issue, we resolved to hide all C++ APIs, ensuring they are not in the same namespace as the system ICU. This solution proves effective for SwiftFoundation, as it does not actually utilize the C++ APIs.