Enable Windows linker discovery #242
Conversation
kcieplak
commented
Feb 28, 2025
kcieplak
commented
kcieplak
requested review from
jakepetroules,
mirza-garibovic,
mhrawdon,
neonichu and
owenv
as code owners
|
@swift-ci test |
kcieplak
force-pushed
the
topics/async-platform-registry-and-windows-link-discovery
branch
from
2940110 to
832055e
Compare
|
@swift-ci test |
|
Making a draft as there seems to be issues where the registry property is accessed before initialized, but only in CI |
kcieplak
force-pushed
the
topics/async-platform-registry-and-windows-link-discovery
branch
from
832055e to
d196b8c
Compare
|
@swift-ci test |
|
@swift-ci test |
kcieplak
force-pushed
the
topics/async-platform-registry-and-windows-link-discovery
branch
from
d196b8c to
daba3aa
Compare
|
@swift-ci test |
| #expect(installedLinkerPaths.map { $0.str }.contains(where: output.asString.contains)) | ||
| if runDestination == .windows && Architecture.hostStringValue == "aarch64" { | ||
| withKnownIssue("'clang' picks the wrong binary for link.exe using x86 version") { | ||
| // On windows aarch64 'clang' picks the wrong host architecture for link.exe, choosing "MSVC\14.41.34120\bin\Hostx86\arm64\link.exe" |
There was a problem hiding this comment.
Is this a clang bug or we're passing in the wrong environment? Can we get an issue filed for this if needed?
There was a problem hiding this comment.
I looked at my PATH and the arm64 path is the only path I can see, yet if you invoke clang with a fake.o to link you can see it picks the x86 host
C:\Users\kcieplak\swift-build>clang -v foobar.o clang version 17.0.6 Target: aarch64-unknown-windows-msvc Thread model: posix InstalledDir: C:\Users\kcieplak\AppData\Local\Programs\Swift\Toolchains\6.0.3+Asserts\usr\bin "C:\\Program Files\\Microsoft Visual Studio\\2022\\Community\\VC\\Tools\\MSVC\\14.41.34120\\bin\\Hostx86\\arm64\\link.exe"
And my PATH
Path=C:\Program Files\Parallels\Parallels Tools\Applications;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit\;C:\Program Files\Git\cmd;C:\Program Files\WindowsPowerShell\Scripts;C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.41.34120\bin\Hostarm64\arm64\
I will open an issue for this
There was a problem hiding this comment.
What if you pass an explicit target triple to clang? Like clang -target aarch64-unknown-windows-pc
There was a problem hiding this comment.
Still the incorrect host linker.
C:\Users\kcieplak\swift-build>clang -v -target aarch64-unknown-windows-pc foobar.o clang version 17.0.6 Target: aarch64-pc-windows-msvc Thread model: posix InstalledDir: C:\Users\kcieplak\AppData\Local\Programs\Swift\Toolchains\6.0.3+Asserts\usr\bin "C:\\Program Files\\Microsoft Visual Studio\\2022\\Community\\VC\\Tools\\MSVC\\14.41.34120\\bin\\Hostx86\\arm64\\link.exe"
There was a problem hiding this comment.
I'm not sure why it's picking Hostx86 for you, but that's not a problem as long as the target arch (arm64) is correct, which it is here.
Can you update the PR to pass in the target triple?
There was a problem hiding this comment.
Agreed this is not really a problem as long as you have 'Prism' emulation enabled, the x86 binary will execute and correctly link to the target arm64 architecture. At worst it will be slightly less performant as emulation will need to run.
And I can confirm that swift-build is indeed providing the correct target triplet when using clang as the linker driver
"C:\\Users\\kcieplak\\AppData\\Local\\Programs\\Swift\\Toolchains\\6.0.3+Asserts\\usr\\bin\\clang.exe", "-target", "aarch64-unknown-windows-msvc",
|
@swift-ci test |
|
There are failures for both the macOS and Windows test pipelines. These failures are occurring in other PRs as well (https://ci-external.swift.org/job/swift-build-pull-request-windows/177/changes) , so not isolated to my changes. In the Windows case the toolchain executables seem to just be exiting with signal 2. macOS seems to have issues with the compiler driver. |
|
@swift-ci test |
|
macOS failures are due to swift-driver |
|
@swift-ci test |
kcieplak
force-pushed
the
topics/async-platform-registry-and-windows-link-discovery
branch
from
daba3aa to
398e93d
Compare
|
@swift-ci test |
kcieplak
force-pushed
the
topics/async-platform-registry-and-windows-link-discovery
branch
from
398e93d to
9d9b923
Compare
|
@swift-ci test |
|
@swift-ci test |
|
FYI you need to rebase this as it conflicts with main |
kcieplak
force-pushed
the
topics/async-platform-registry-and-windows-link-discovery
branch
from
fe2478d to
a8d9e01
Compare
|
@swift-ci test |
Fixing up now, had conflicts with two PR merges. |
kcieplak
force-pushed
the
topics/async-platform-registry-and-windows-link-discovery
branch
2 times, most recently
from
7da6cc2 to
bdcdb21
Compare
|
@swift-ci test |
|
@swift-ci test |
1 similar comment
|
@swift-ci test |
|
@swift-ci test |
Tests/SWBCoreTests/CommandLineToolSpecDiscoveredInfoTests.swift
Outdated
Show resolved
Hide resolved
* Make Platform Registry initialization async * Change the function signature of additionalPlatformExecutableSearchPaths to allow passing of a filesystem for discovery. Plugins will need to be updated to match new signatures * Add the visual studio install directory to platform search paths for executables. * Enable Windows linker discovery to get link.exe type and version * Add Windows platform plugin extension to get install directory * Add test for discovery of windows linker * Paths in the clang ouput have double slashes so this needs to be handled.
The link.exe cannot link for multiple architectures there
is a distinct link.exe for arm86 and x86_64.
The path to the specific linkers should not be added to the
global search path, as when building a target we do not know
the architecture until task creation time.
* Only add up until the Host[x86|arm]/bin directory to the
global search path.
* Let the LD spec determine the correct prefix directory
to find the proper link.exe
* Introduce two build settings
LD_MULTIARCH - A boolean indicator for multiple architecture support
LD_MULTIARCH_PREFIX_MAP - A prefix directory map from architecture:prefix
* Add in specfic tests for discoveredLdLinkerSpecInfo for each linkers
* Add x86_64 as a supported architecture for windows. A seperate PR
is inflight to add the true supported set.
* Rename LD_MULTIARCH to _LD_MULTIARCH. This build setting should not be used by external clients, so hide it using the underscore notation. * Add in mappings for future supported architectures i386 and thumbv7. * Drop arm64->arm64 mapping, handled by aarch64. * Fix logic parsing for architecture prefix mappings, could have crashed accessing out of bound element. * Rebase changes ontop of SDK platform registration refactor.
kcieplak
force-pushed
the
topics/async-platform-registry-and-windows-link-discovery
branch
from
bdcdb21 to
dce4d12
Compare
|
@swift-ci test |
Crash on Linux and MacOS, seen in other PRs not isolated to this change |
|
@swift-ci test |
kcieplak
force-pushed
the
topics/async-platform-registry-and-windows-link-discovery
branch
from
dce4d12 to
a152936
Compare
* Move discoveredLdLinkerSpecInfo_Windows to the windows platform tests. * Use the helper functions to make linker tests conditional on the presence of specific host SDK components. * Update target architectures to match windows SDK.
kcieplak
force-pushed
the
topics/async-platform-registry-and-windows-link-discovery
branch
from
a152936 to
31ecfbd
Compare
|
@swift-ci test |
