Skip to content

Only add '-fobjc-link-runtime' to the linker invocation when the driver is invoked with '-link-objc-runtime' #1224

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.

Sign up for GitHub

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
Nov 15, 2022
Merged

Only add '-fobjc-link-runtime' to the linker invocation when the driver is invoked with '-link-objc-runtime' #1224

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 7 additions & 2 deletions Sources/SwiftDriver/Jobs/DarwinToolchain+LinkerSupport.swift
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -214,9 +214,14 @@ extension DarwinToolchain {
commandLine.appendPath(VirtualPath.lookup(sdkPath))
}

// -link-objc-runtime also implies -fobjc-link-runtime
if parsedOptions.hasFlag(positive: .linkObjcRuntime,
Copy link
Member

Choose a reason for hiding this comment

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

Is this an existing option? Why not gate this on -enable-objc-interop?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

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...

Copy link
Member

Choose a reason for hiding this comment

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

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

-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.

Copy link
Member

Choose a reason for hiding this comment

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

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.

Copy link

Choose a reason for hiding this comment

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

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.

Copy link

Choose a reason for hiding this comment

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

(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)

negative: .noLinkObjcRuntime,
default: false) {
commandLine.appendFlag("-fobjc-link-runtime")
}

commandLine.appendFlags(
"-fobjc-link-runtime",
"-lobjc",
"-lSystem"
)

Expand Down
35 changes: 35 additions & 0 deletions Tests/SwiftDriverTests/SwiftDriverTests.swift
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1653,6 +1653,8 @@ final class SwiftDriverTests: XCTestCase {

XCTAssertFalse(cmd.contains(.flag("-static")))
XCTAssertFalse(cmd.contains(.flag("-shared")))
// Handling of '-lobjc' is now in the Clang linker driver.
XCTAssertFalse(cmd.contains(.flag("-lobjc")))
}

do {
Expand Down Expand Up @@ -1728,6 +1730,39 @@ final class SwiftDriverTests: XCTestCase {
XCTAssertFalse(cmd.contains(.flag("-shared")))
}

do {
// -fobjc-link-runtime default
var driver = try Driver(args: commonArgs + ["-emit-library", "-target", "x86_64-apple-macosx10.15"], env: env)
let plannedJobs = try driver.planBuild()
XCTAssertEqual(3, plannedJobs.count)
let linkJob = plannedJobs[2]
XCTAssertEqual(linkJob.kind, .link)
let cmd = linkJob.commandLine
XCTAssertFalse(cmd.contains(.flag("-fobjc-link-runtime")))
}

do {
// -fobjc-link-runtime enable
var driver = try Driver(args: commonArgs + ["-emit-library", "-target", "x86_64-apple-macosx10.15", "-link-objc-runtime"], env: env)
let plannedJobs = try driver.planBuild()
XCTAssertEqual(3, plannedJobs.count)
let linkJob = plannedJobs[2]
XCTAssertEqual(linkJob.kind, .link)
let cmd = linkJob.commandLine
XCTAssertTrue(cmd.contains(.flag("-fobjc-link-runtime")))
}

do {
// -fobjc-link-runtime disable override
var driver = try Driver(args: commonArgs + ["-emit-library", "-target", "x86_64-apple-macosx10.15", "-link-objc-runtime", "-no-link-objc-runtime"], env: env)
let plannedJobs = try driver.planBuild()
XCTAssertEqual(3, plannedJobs.count)
let linkJob = plannedJobs[2]
XCTAssertEqual(linkJob.kind, .link)
let cmd = linkJob.commandLine
XCTAssertFalse(cmd.contains(.flag("-fobjc-link-runtime")))
}

do {
// Xlinker flags
// Ensure that Xlinker flags are passed as such to the clang linker invocation.
Expand Down