-
Notifications
You must be signed in to change notification settings - Fork 10.5k
Driver: prevent C++ runtime linkage #26110
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
Driver: prevent C++ runtime linkage #26110
Conversation
CC: @jrose-apple |
@swift-ci please test |
lib/Driver/UnixToolChains.cpp
Outdated
// `--as-needed` however that breaks other Unix semantics of linking where | ||
// the dependency on the library is not visible to the linker should still be | ||
// linked upon request). | ||
Arguments.push_back("-nostdlib++"); |
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.
Where does the C++ runtime get linked, then?
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.
Why would you need the C++ runtime? Swift doesn't yet allow importing C++, so there is no dependency from any Swift code on the C++ runtime. If you are worried about the standard library, that explicitly links in C++ mode using clang++
rather than the swift driver (separate issue). If you have dependencies which rely on C++, they will be linked against the C++ runtime.
On android you should be linking against stl_port (or if you are targeting something in the future, libc++). On Linux, you should be linking against libstdc++ unless you are running a custom closed environment that is libc++ based. On Windows, you should be linking against msvcprt unless you are using libc++ across your application. On Darwin, you should link against libc++. Because you have multiple options based on the target, we need to either make this explicit from the user at some point. But, given that we currently do not support importing C++ code, I think that we can deal with that issue when the time comes.
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.
Just chiming in here- I don't know enough about this to have a strong opinion either way, but I did notice I have to add -Xclang-linker -nostdlib++
to swiftc
invocations to prevent libc++
being linked for Swift(-only) binaries on Android with recent compiler versions.
Adding the flag doesn't seem to have any negative effect, but again, I'm far from an expert at this. There's a reason for everything :)
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.
I was thinking about static linking, but I think that's already covered with an explicit -lc++
and I just forgot. Sorry for the distraction!
Build failed |
Hmm, I think that it is falling back to the system clang which may be older than 7.0 which introduced the flag. I'm not sure what the best way to handle this is. I guess I can restrict this to just android for the time being, though this should apply equally to all Unices. |
38afc15
to
a4336f8
Compare
@swift-ci please test |
Build failed |
Build failed |
a4336f8
to
13f41f2
Compare
@swift-ci please test |
Build failed |
Build failed |
My take is to merge this as is for now, with the caveat that it absolutely shouldn't be left this way any longer than it needs to be. The stopgap is, I think, worth it. |
Another option: go down to |
@jrose-apple - yeah, I did consider that, but that means that we also loose out on |
13f41f2
to
dc597fd
Compare
@swift-ci please test |
lib/Driver/UnixToolChains.cpp
Outdated
@@ -153,14 +159,13 @@ toolchains::GenericUnix::constructInvocation(const DynamicLinkJobAction &job, | |||
|
|||
// Configure the toolchain. | |||
// By default, use the system clang++ to link. |
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.
Comment needs correction (and would probably be a good place to explain why someone shouldn't just change it back to clang++
).
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.
sigh that is what happens when you try to be quick. Thanks for pointing that out. (I'll wait until the tests complete to update the diff).
Build failed |
Build failed |
dc597fd
to
e22137b
Compare
@swift-ci please test |
@swift-ci please test Windows platform |
Build failed |
Build failed |
@swift-ci please test macOS platform |
Build failed |
e22137b
to
4fa9fe4
Compare
@swift-ci please test |
Build failed |
Build failed |
4fa9fe4
to
e8b4ef5
Compare
@swift-ci please test |
Build failed |
Build failed |
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.
The "fake" clang++
that was renamed to clang
in test/Driver/Inputs/fake-toolchain/
has lost the executable bits, and so it is not found by the UnixToolChains.cpp
and making the tools_directory.swift
test fail.
e8b4ef5
to
32e1342
Compare
@swift-ci please test |
Build failed |
32e1342
to
3a32c2f
Compare
@swift-ci please test |
Build failed |
Build failed |
Use `clang` rather than `clang++` as the linker driver. This ensures that we do not force a C++ runtime on the general code. This is fine for now as C++ interop is not yet available for Swift. This prevents the accidental mix-and-match of various C++ runtimes. This can cause problems on platforms like android where `libstdc++` is an unsupported runtime but is generally the default for Linux platforms.
3a32c2f
to
67475dc
Compare
@swift-ci please test |
Build failed |
Build failed |
Replace this paragraph with a description of your changes and rationale. Provide links to external references/discussions if appropriate.
Resolves SR-NNNN.