Only add '-fobjc-link-runtime' to the linker invocation when the driver is invoked with '-link-objc-runtime' #1224
Conversation
|
@swift-ci test |
| @@ -214,8 +214,14 @@ extension DarwinToolchain { | |||
| commandLine.appendPath(VirtualPath.lookup(sdkPath)) | |||
| } | |||
|
|
|||
| // -link-objc-runtime also implies -fobjc-link-runtime | |||
| if parsedOptions.hasFlag(positive: .linkObjcRuntime, | |||
There was a problem hiding this comment.
Is this an existing option? Why not gate this on -enable-objc-interop?
There was a problem hiding this comment.
It is an existing option and seems to very explicitly map to Clang's equivalent.
I am not sure if there are cases where -enable-objc-interop is set where we wouldn't want to do this though, explicit override with -no-link-obcj-runtime aside...
There was a problem hiding this comment.
The only question then is, is there ever a case where you want to link the ObjC runtime (and Foundation) when ObjC is explicitly disabled? If not, I feel like -enable-objc-interop is nicer.
There was a problem hiding this comment.
-enable-objc-interop is actually a frontend-only flag (.noDriver) that the driver sets to be on by-default for Darwin platforms, always.
So we cannot use it as an input switch to enable/disable this. And if we did, because it is enabled by the driver by-default, it would essentially be equivalent to what things were like before this change. I may lack some historical context here, but the existence of -link-objc-runtime really indicates that it ought to be used to control this behavior.
There was a problem hiding this comment.
Yeah, as a short term thing, I don't think that it is terrible. But it seems like having an extra flag that is unnecessary and we should figure out how to deprecate that IMO. Having the language runtime be linked in properly based on the build type seems like the right approach.
There was a problem hiding this comment.
It's not that there are cases where you want this without ObjC, but there are cases where you want ObjC without this. For example, if you're in a binary which Foundation itself links.
There was a problem hiding this comment.
(and then you manually link the runtime of course. I'm not aware of a situation where you want ObjC support but not the ObjC runtime, it's just Foundation that makes things tricky)
artemcm
force-pushed
the
INeverAskedForThisFoundation
branch
from
d52a7f7 to
10a1437
Compare
|
@swift-ci test |
artemcm
force-pushed
the
INeverAskedForThisFoundation
branch
from
10a1437 to
573c4f7
Compare
artemcm
changed the title
|
@swift-ci test |
…er is invoked with '-link-objc-runtime' Resolves rdar://100994806
artemcm
force-pushed
the
INeverAskedForThisFoundation
branch
from
573c4f7 to
cc83760
Compare
|
@swift-ci test |
|
This might be causing CI failures in LLDB. Speculatively reverting to do more testing |
Otherwise, every single compiled program will end up linking it, and Foundation on top of it.