Description
Follow-up from #773.
For Swift SDK / WASI test builds, the actual runnable output is a SwiftPM-synthesized test runner target. If linker flags remain only on the unit test product and are not copied to the synthetic runner, the produced .wasm executable can miss required linker settings.
The minimum reproducer has:
- a header-only system library target,
CHelper, exposing helper_value()
Vendor/helper.c, which the repro script builds into a WASI archive at Vendor/libhelper.a
Lib, which calls helper_value()
LibTests, which supplies -L <Vendor> -lhelper through test-target linkerSettings
Updated reproducer zip: https://gist.githubusercontent.com/kateinoigakukun/ba21c654a675032aa77906877c906e53/raw/e95f44931cc10b5f6197d93f42cffc9991faa478/updated-777-test-runner-ldflags-linux-2026-06-12.zip
The updated zip preserves the original repro package and original repro.sh, and also includes repro-linux-2026-06-12.sh plus adaptation notes for running the same reproducer with the Linux June 12 snapshot toolchain and Swift SDK.
Expected behavior
The generated SwiftPM test runner should inherit the relevant linker flags from the unit test product in both Debug and Release, including platform-specific linker settings.
For this reproducer, the synthetic LibTests-test-runner.wasm link should include the test target's -L <Vendor> -lhelper flags and should resolve helper_value.
Actual behavior
With the June 12, 2026 development snapshot and swift-DEVELOPMENT-SNAPSHOT-2026-06-12-a_wasm, the native backend succeeds and SwiftBuild still reproduces the original failure.
Observed in the latest verification:
native exit: 0
swiftbuild exit: 1
native -lhelper count: 3
swiftbuild -lhelper count: 0
The SwiftBuild link step for the synthetic runner:
Link LibTests-test-runner.wasm (wasm32)
does not include -lhelper, then fails with:
wasm-ld: error: .../libLibTests.a(Lib.o): undefined symbol: helper_value
Steps to reproduce
-
Download and unzip https://gist.githubusercontent.com/kateinoigakukun/ba21c654a675032aa77906877c906e53/raw/e95f44931cc10b5f6197d93f42cffc9991faa478/updated-777-test-runner-ldflags-linux-2026-06-12.zip.
-
Enter the package directory:
cd 777-test-runner-ldflags
-
On this Linux verification machine, run the adapted script:
./repro-linux-2026-06-12.sh
The adapted script uses:
/home/ubuntu/.local/share/swiftly/toolchains/main-snapshot-2026-06-12/usr/bin/swift
swift-DEVELOPMENT-SNAPSHOT-2026-06-12-a_wasm
It also builds Vendor/libhelper.a from the original Vendor/helper.c before running the build-system comparison.
-
On a machine matching the original macOS-style repro assumptions, the original script is still available:
-
The script runs the same comparison for both build systems:
swift build --package-path "$ROOT" --scratch-path "$WORK/native" --swift-sdk "$SWIFT_SDK_ID" --build-tests --build-system native -v
swift build --package-path "$ROOT" --scratch-path "$WORK/swiftbuild" --swift-sdk "$SWIFT_SDK_ID" --build-tests --build-system swiftbuild -v
-
Expected reproducer result for the current bug: native exits 0; SwiftBuild exits nonzero while linking LibTests-test-runner.wasm with undefined symbol: helper_value.
Swift Package Manager version/commit hash
Swift Package Manager - Swift 6.5.0-dev
Swift & OS version (output of swift --version ; uname -a)
Swift version 6.5-dev (LLVM 18d2bfb70c14d89, Swift c13d82e5987aecb)
Target: x86_64-unknown-linux-gnu
Build config: +assertions
Linux swift-dev.fugu.katei.dev 6.8.0-94-generic #96-Ubuntu SMP PREEMPT_DYNAMIC Fri Jan 9 20:36:55 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux
Description
Follow-up from #773.
For Swift SDK / WASI test builds, the actual runnable output is a SwiftPM-synthesized test runner target. If linker flags remain only on the unit test product and are not copied to the synthetic runner, the produced
.wasmexecutable can miss required linker settings.The minimum reproducer has:
CHelper, exposinghelper_value()Vendor/helper.c, which the repro script builds into a WASI archive atVendor/libhelper.aLib, which callshelper_value()LibTests, which supplies-L <Vendor> -lhelperthrough test-targetlinkerSettingsUpdated reproducer zip:
https://gist.githubusercontent.com/kateinoigakukun/ba21c654a675032aa77906877c906e53/raw/e95f44931cc10b5f6197d93f42cffc9991faa478/updated-777-test-runner-ldflags-linux-2026-06-12.zipThe updated zip preserves the original repro package and original
repro.sh, and also includesrepro-linux-2026-06-12.shplus adaptation notes for running the same reproducer with the Linux June 12 snapshot toolchain and Swift SDK.Expected behavior
The generated SwiftPM test runner should inherit the relevant linker flags from the unit test product in both Debug and Release, including platform-specific linker settings.
For this reproducer, the synthetic
LibTests-test-runner.wasmlink should include the test target's-L <Vendor> -lhelperflags and should resolvehelper_value.Actual behavior
With the June 12, 2026 development snapshot and
swift-DEVELOPMENT-SNAPSHOT-2026-06-12-a_wasm, the native backend succeeds and SwiftBuild still reproduces the original failure.Observed in the latest verification:
The SwiftBuild link step for the synthetic runner:
does not include
-lhelper, then fails with:Steps to reproduce
Download and unzip
https://gist.githubusercontent.com/kateinoigakukun/ba21c654a675032aa77906877c906e53/raw/e95f44931cc10b5f6197d93f42cffc9991faa478/updated-777-test-runner-ldflags-linux-2026-06-12.zip.Enter the package directory:
cd 777-test-runner-ldflagsOn this Linux verification machine, run the adapted script:
The adapted script uses:
It also builds
Vendor/libhelper.afrom the originalVendor/helper.cbefore running the build-system comparison.On a machine matching the original macOS-style repro assumptions, the original script is still available:
The script runs the same comparison for both build systems:
Expected reproducer result for the current bug: native exits
0; SwiftBuild exits nonzero while linkingLibTests-test-runner.wasmwithundefined symbol: helper_value.Swift Package Manager version/commit hash
Swift & OS version (output of
swift --version ; uname -a)