You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is it reproducible with SwiftPM command-line tools: swift build, swift test, swift package etc?
Confirmed reproduction steps with SwiftPM CLI. The description text must include reproduction steps with either of command-line SwiftPM commands, swift build, swift test, swift package etc.
Description
For a simple executable package (e.g., swift package init --type executable), the legacy PIF builder in SwiftPM would make a very simple target that takes the main.swift and uses the compiler driver to directly produce an executable without any intermediate targets/stages.
We're currently relying on this on Windows because we don't have a story for handling the so called partial linking problem that would be encountered for basically anything that's more complex than this one-file executable.
The PIF from the new PIF Builder (in SwiftBuildSupport) is producing a build setting MACH_O_TYPE that's set to mh_object. This setting will cause Swift Build to try and combine multiple *.o(obj) files into a single *.o (obj), aka: partial linking. With Windows, the error message will be something like this:
lld-link: error: subsystem must be defined
clang: error: linker command failed with exit code 1 (use -v to see invocation)
error: Build failed
which happens because the Windows linker is being invoked in what it thinks is to produce the final executable (i.e., that needs a subsystem command-line flag), but Swift Build is trying to get it to partial link object files into another bigger object file.
In order to not regress from the legacy PIF builder behaviour, it's important to preserve the PIF targets structure to avoid the extra target with the mh_object setting in these simple cases with the one-file -> executable packages.
Swift & OS version (output of swift --version ; uname -a)
swift-driver version: 1.125.2 Apple Swift version 6.2
(swiftlang-6.2.0.5.56 clang-1700.3.5.51)
Target: arm64-apple-macosx15.0
Darwin Paulos-MacBook-Pro.local 24.5.0 Darwin Kernel Version 24.5.0:
Sat Mar 29 11:59:10 PDT 2025;
root:xnu_development-11417.120.87.0.3~5/DEVELOPMENT_ARM64_T6020 arm64
The text was updated successfully, but these errors were encountered:
…ld system (#8527)
### Motivation:
Increase code coverage for our integration tests.
This is an issue I introduced in #8454 while ignoring
`--build-system swiftbuild` issues on Windows (i.e., actually this
specific issue #8514). I accidentally skipped the packageInitExecutable
test for `--build-system native` as well (which should be green).
This PR fixes that.
### Modifications:
Swift Testing currently doesn't support combining *conditional traits*
(e.g.,`skipHostOS(.windows)`) with *parametric tests*. So the 2nd
best approach is to split the tests as I just did.
Is it reproducible with SwiftPM command-line tools:
swift build
,swift test
,swift package
etc?swift build
,swift test
,swift package
etc.Description
For a simple executable package (e.g.,
swift package init --type executable
), the legacy PIF builder in SwiftPM would make a very simple target that takes themain.swift
and uses the compiler driver to directly produce an executable without any intermediate targets/stages.We're currently relying on this on Windows because we don't have a story for handling the so called partial linking problem that would be encountered for basically anything that's more complex than this one-file executable.
The PIF from the new PIF Builder (in
SwiftBuildSupport
) is producing a build settingMACH_O_TYPE
that's set tomh_object
. This setting will cause Swift Build to try and combine multiple*.o
(obj) files into a single*.o
(obj), aka: partial linking. With Windows, the error message will be something like this:which happens because the Windows linker is being invoked in what it thinks is to produce the final executable (i.e., that needs a subsystem command-line flag), but Swift Build is trying to get it to partial link object files into another bigger object file.
In order to not regress from the legacy PIF builder behaviour, it's important to preserve the PIF targets structure to avoid the extra target with the
mh_object
setting in these simple cases with the one-file -> executable packages.This regression was introduced by #8454.
Expected behavior
N/A
Actual behavior
N/A
Steps to reproduce
SwiftPMTests.packageInitExecutable
with--build-system swiftbuild
.Swift Package Manager version/commit hash
393a8f3
Swift & OS version (output of
swift --version ; uname -a
)swift-driver version: 1.125.2 Apple Swift version 6.2 (swiftlang-6.2.0.5.56 clang-1700.3.5.51) Target: arm64-apple-macosx15.0 Darwin Paulos-MacBook-Pro.local 24.5.0 Darwin Kernel Version 24.5.0: Sat Mar 29 11:59:10 PDT 2025; root:xnu_development-11417.120.87.0.3~5/DEVELOPMENT_ARM64_T6020 arm64
The text was updated successfully, but these errors were encountered: