Update Generic Unix linker selection#1545
Merged
etcwilde merged 2 commits intoswiftlang:mainfrom May 6, 2024
Merged
Conversation
Member
Author
|
swiftlang/llvm-project#8214 |
compnerd
approved these changes
Feb 16, 2024
Member
compnerd
left a comment
There was a problem hiding this comment.
This seems like the right approach, we use clang as the linker driver to avoid re-constructing the full linker invocation logic.
Member
|
@swift-ci please test Windows platform |
keith
approved these changes
Feb 16, 2024
artemcm
approved these changes
Feb 20, 2024
5bd86f6 to
9920128
Compare
Member
Author
|
@swift-ci please test |
finagolfin
approved these changes
Mar 4, 2024
Member
finagolfin
left a comment
There was a problem hiding this comment.
Thanks, this is a good change that we probably should've been doing all along.
Contributor
|
@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
9920128 to
c11743b
Compare
Member
Author
|
@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 ? |
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
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