Skip to content

[5.1] Introduce a backward-deployment library for SR-10600. #25330

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

Conversation

jckarter
Copy link
Contributor

Build a static archive that can be linked into executables and take advantage of the Swift runtime's
hooking mechanism to work around the issue Doug fixed in #24759.
The Swift 5.0 version of swift_conformsToProtocol would return a false negative in some cases where
a subclass conforms using an inherited conformance, so work around this by successively retrying
the original implementation up the superclass chain to try to find a match.

rdar://problem/50057445

jckarter added 6 commits June 10, 2019 11:31
Build a static archive that can be linked into executables and take advantage of the Swift runtime's
hooking mechanism to work around the issue Doug fixed in swiftlang#24759.
The Swift 5.0 version of swift_conformsToProtocol would return a false negative in some cases where
a subclass conforms using an inherited conformance, so work around this by successively retrying
the original implementation up the superclass chain to try to find a match.
Many build systems that support Swift don't use swiftc to drive the linker. To make things
easier for these build systems, also use autolinking to pull in the needed compatibility
libraries. This is less ideal than letting the driver add it at link time, since individual
compile jobs don't know whether they're building an executable or not. Introduce a
`-disable-autolink-runtime-compatibility` flag, which build systems that do drive the linker
with swiftc can pass to avoid autolinking.

rdar://problem/50057445
Although it's a static archive, its use is only relevant to dynamically linked builds of the
standard library. (If you're statically linking a Swift runtime into your process, you don't
need to worry about compatibility with older runtimes.)
@jckarter
Copy link
Contributor Author

@swift-ci Please test

@jckarter
Copy link
Contributor Author

Please test with following pull request:
swiftlang/swift-package-manager#2147

@swift-ci Please test

@jckarter
Copy link
Contributor Author

Please test with following pull request:
swiftlang/swift-package-manager#2147

@swift-ci Please test

@swift-ci
Copy link
Contributor

Build failed
Swift Test OS X Platform
Git Sha - 31206ea

@jckarter
Copy link
Contributor Author

@swift-ci Please test OS X

@swift-ci
Copy link
Contributor

Build failed
Swift Test OS X Platform
Git Sha - 31206ea

@jckarter
Copy link
Contributor Author

@swift-ci Please test OS X

@swift-ci
Copy link
Contributor

Build failed
Swift Test OS X Platform
Git Sha - 31206ea

@jckarter
Copy link
Contributor Author

Please test with following pull request:
swiftlang/swift-package-manager#2147

@swift-ci Please test OS X

@jckarter jckarter merged commit c94abaf into swiftlang:swift-5.1-branch Jun 12, 2019
jckarter added a commit to jckarter/swift-package-manager that referenced this pull request Jun 12, 2019
Using Swift to link pure C targets relies on a new Swift driver flag
introduced in swiftlang/swift#25330. Stage this in
by disabling tests until that change propagates.

rdar://problem/50057445
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