Skip to content

Integration test SwiftPMTests.packageInitExecutable with --build-system swiftbuild is skipped on Windows #8514

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Open
1 task done
pmattos opened this issue Apr 16, 2025 · 0 comments
Labels
bug swift build Changes impacting `swift build` windows

Comments

@pmattos
Copy link
Contributor

pmattos commented Apr 16, 2025

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.

This regression was introduced by #8454.

Expected behavior

N/A

Actual behavior

N/A

Steps to reproduce

  1. Using Windows.
  2. Run integration test 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
@pmattos pmattos added bug swift build Changes impacting `swift build` windows labels Apr 16, 2025
pmattos added a commit that referenced this issue Apr 23, 2025
…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.
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
bug swift build Changes impacting `swift build` windows
Projects
None yet
Development

No branches or pull requests

1 participant