Update Generic Unix linker selection #1545
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
swiftlang/llvm-project#8214 |
compnerd
approved these changes
Feb 16, 2024
|
@swift-ci please test Windows platform |
keith
approved these changes
Feb 16, 2024
artemcm
approved these changes
Feb 20, 2024
etcwilde
force-pushed
the
ewilde/linker-selection
branch
from
5bd86f6 to
9920128
Compare
|
@swift-ci please test |
finagolfin
approved these changes
Mar 4, 2024
|
@swift-ci test windows |
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
force-pushed
the
ewilde/linker-selection
branch
from
9920128 to
c11743b
Compare
|
@swift-ci please test |
shahmishal
approved these changes
May 4, 2024
drodriguez
added a commit
to drodriguez/swift-driver
that referenced
this pull request
May 30, 2024
The spelling of the linker is `-fuse-ld=`, not `--fuse-ld=`, as it can be seen in [1] and as used in the C++ driver in [2]. The code was correct before swiftlang#1545 using `-fuse-ld=`, but was changed to `--fuse-ld=`. The test was testing for the command line containing the same spelling, so it would had never failed, but running the actual command line would had failed. That code was eventually reverted and reverted back in swiftlang#1608. [1]: https://github.com/apple/llvm-project/blob/e33819dff1cbf7a90b0216a4993126cb11440d45/clang/include/clang/Driver/Options.td#L5267 [2]: https://github.com/apple/swift/blob/319f36b01baa082fd2d2640d6e320594752702d0/lib/Driver/UnixToolChains.cpp#L234
|
@MaxDesiatov @etcwilde This has been merged in Can we include this change in one of the next release ? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
lldas the linker.LLD removes the start/stop symbols as of https://reviews.llvm.org/D96914, which the Swift runtime used to register the runtime type metadata and other runtime metadata tables. I'm waiting to merge this until swiftlang/swift#72061 merges as we won't know when to pass
nostart-stop-gcwith this change.Fixes: rdar://123061492