Skip to content

[Build][Backtracing] Make sure the target for OS X is at least 10.14.4. #75709

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

Merged
merged 1 commit into from
Aug 9, 2024

Conversation

al45tair
Copy link
Contributor

@al45tair al45tair commented Aug 6, 2024

We need to make sure that we build swift-backtrace with a deployment target newer than 10.14.4 in order that we get linked against /usr/lib/swift/libswiftCore.dylib rather than using an @rpath-based path.

If we fail to do that, dyld becomes confused and we end up crashing with weird errors about missing method implementations on Swift.__StringStorage.

To make this work, add support for DEPLOYMENT_VERSION_* in the add_swift_target_executable() CMake function. And since I spotted a bug in it, fix the existing support in add_swift_target_library() while I'm there.

rdar://132710670

… 10.14.4.

We need to make sure that we build swift-backtrace with a deployment target
newer than 10.14.4 in order that we get linked against
`/usr/lib/swift/libswiftCore.dylib` rather than using an `@rpath`-based
path.

If we fail to do that, dyld becomes confused and we end up crashing with
weird errors about missing method implementations on `Swift.__StringStorage`.

To make this work, add support for `DEPLOYMENT_VERSION_*` in the
`add_swift_target_executable()` CMake function.  And since I spotted a bug
in it, fix the existing support in `add_swift_target_library()` while I'm
there.

rdar://132710670
@al45tair al45tair requested review from edymtt and eeckstein August 6, 2024 14:07
@al45tair al45tair requested a review from a team as a code owner August 6, 2024 14:07
@al45tair
Copy link
Contributor Author

al45tair commented Aug 6, 2024

Note: this doesn't affect the overall correctness of the final build. It just fixes problems with the tests.

@al45tair
Copy link
Contributor Author

al45tair commented Aug 6, 2024

@swift-ci Please smoke test

DEPLOYMENT_VERSION_TVOS "${SWIFTLIB_DEPLOYMENT_VERSION_TVOS}"
DEPLOYMENT_VERSION_WATCHOS "${SWIFTLIB_DEPLOYMENT_VERSION_WATCHOS}"
DEPLOYMENT_VERSION_XROS "${SWIFTLIB_DEPLOYMENT_VERSION_XROS}"
DEPLOYMENT_VERSION_OSX "${SWIFTLIB_SINGLE_DEPLOYMENT_VERSION_OSX}"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice catch, thanks for taking care of this!

Turns out this has been working by accident so far since in CMake variables defined by a function are visible in any other function called by it -- since in general we tend to call add_swift_target_library, when we get here we are able to see SWIFTLIB_DEPLOYMENT_VERSION_* that the caller defined.

I don't foresee issues in the scenarios in which we are calling add_swift_target_library_single directly (embedded, and building part of the stdlib to support bootstrapping) -- in those we are not forcing a specific deployment target (if we were, we would have noticed this issue before).

@al45tair al45tair merged commit a95b69c into swiftlang:main Aug 9, 2024
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants