Skip to content
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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

馃崚[Swift 6.0]: Update Generic Unix linker selection #1595

Open
wants to merge 2 commits into
base: release/6.0
Choose a base branch
from

Conversation

etcwilde
Copy link
Member

@etcwilde etcwilde commented May 6, 2024

Cherry-Picking #1545 back to Swift 6.0

Not all generic-"unix" environments have the Gold linker available to them, and in some cases, the vendor of the toolchain may provide their own linker. In these cases, the driver should be internally consistent with the toolchain that it is shipped with.

Now that we have the clang-linker, we can lean on the linker selection in the clang-linker to determine a default linker. If the clang-linker, and thus, the swift compiler driver, are part of a specific toolchain, that clang-linker should be built for that platform with the appropriate linker defaults set. If someone overrides the linker with -use-ld, we should still honour that, but should otherwise be consistent with the appropriate toolchain linker.

This will enable building and linking on AmazonLinux 2023 without requiring folks to always pass additional flags. It also means we can produce a self-contained toolchain that is internally consistent using lld as the linker.

Fixes: rdar://123061492

Not all generic-"unix" environments have the Gold linker available to
them, and in some cases, the vendor of the toolchain may provide their
own linker. In these cases, the driver should be internally consistent
with the toolchain that it is shipped with.

Now that we have the clang-linker, we can lean on the linker selection
in the clang-linker to determine a default linker. If the clang-linker,
and thus, the swift compiler driver, are part of a specific toolchain,
that clang-linker should be built for that platform with the appropriate
linker defaults set. If someone overrides the linker with
`-use-ld`, we should still honour that, but should otherwise be
consistent with the appropriate toolchain linker.

Fixes: rdar://123061492
@etcwilde
Copy link
Member Author

etcwilde commented May 6, 2024

Explanation: This patch has the Swift driver fallback on the clang-linker for default linker selection instead of hard-coding gold on Linux. The clang-linker can be configured to choose a different linker at build time, which means that we can have a toolchain that "just works" on Amazon Linux 2023, which does not have gold, but does have lld.
Original PR: #1545
Reviewed By: @compnerd, @keith, @shahmishal, @artemcm, @finagolfin
Resolves: rdar://123061492
Tests: Several driver tests do not pass an explicit linker, those would fail if a linker weren't being chosen. This is also tested by any part of the SDK build that uses the Swift driver for linking (or clang as it is the clang-linker).

@etcwilde
Copy link
Member Author

etcwilde commented May 6, 2024

@swift-ci please test

@etcwilde
Copy link
Member Author

etcwilde commented May 6, 2024

We'll also need to back-port the corresponding change to the default linker in the clang-linker or the Linux builds will fail: apple/swift#73463

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants