[SwiftBuild] Preserve duplicate archive members when SwiftBuild expands static archives for linking

[kateinoigakukun]

Description

Follow-up from #773.

SwiftBuild's archive expansion path assumes archive member names are unique. Some static archives contain duplicate basenames, and collapsing them during extraction loses object files before the final link, which can show up as missing symbols or malformed outputs.

The attached reproducer is JavaScriptKit-agnostic. It regenerates a binary target archive with two object files that deliberately share the same archive member basename:

common.o
common.o

It then builds a static Wrapper product with both the native/control build system and SwiftBuild, and validates the produced wrapper archive with llvm-ar and llvm-nm.

Expected behavior

When an archive contains duplicate member names, every member should still be preserved during expansion for linking.

Duplicate member basenames should not cause object-file loss during link preparation, and final wasm products should link successfully when archives contain colliding member names.

Actual behavior

With swift-DEVELOPMENT-SNAPSHOT-2026-06-12-a_wasm, the native/control path succeeds and preserves the duplicate archive semantics externally. The native wrapper archive contains only the wrapper objects, while references to both dup_a and dup_b remain unresolved for the external binary archive:

native wrapper archive members:
Wrapper.swiftmodule.o
wrap.swift.o
native symbols include unresolved dup_a and dup_b

The same reproducer with --build-system swiftbuild succeeds as a command, but produces a corrupted libWrapper.a by expanding the duplicate-member archive and retaining only one of the duplicate object definitions:

swiftbuild wrapper archive members:
Wrapper.o
common.o
swiftbuild_dup_symbol_definitions=1

In the verified run, llvm-nm showed only dup_b from the duplicate-member archive in the SwiftBuild-produced wrapper archive.

Steps to reproduce

Updated reproducer zip: https://gist.githubusercontent.com/kateinoigakukun/ba21c654a675032aa77906877c906e53/raw/e7de0e5c875db5dbaf6a4390668ffc811ae51fa1/781-duplicate-archive-members-linux-2026-06-12.zip

The updated zip preserves the original repro.sh and includes repro-linux-2026-06-12.sh plus adaptation notes for the Linux snapshot run.

unzip 781-duplicate-archive-members.zip
cd 781-duplicate-archive-members

TOOLCHAIN=/home/ubuntu/.local/share/swiftly/toolchains/main-snapshot-2026-06-12 \
SWIFT_SDK=swift-DEVELOPMENT-SNAPSHOT-2026-06-12-a_wasm \
SYSROOT=/home/ubuntu/.swiftpm/swift-sdks/swift-DEVELOPMENT-SNAPSHOT-2026-06-12-a_wasm.artifactbundle/swift-DEVELOPMENT-SNAPSHOT-2026-06-12-a_wasm/wasm32-unknown-wasip1/WASI.sdk \
./repro-linux-2026-06-12.sh

On macOS with the original 2026-05-27 snapshot setup described in the original reproducer, ./repro.sh preserves the original invocation shape.

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

[kateinoigakukun]

Minimum reproducer zip is here:

• 781-duplicate-archive-members.zip
• Direct zip URL: https://gist.githubusercontent.com/kateinoigakukun/ba21c654a675032aa77906877c906e53/raw/ecb1d747700ea5b879effae0e73e2e40151514ee/781-duplicate-archive-members.zip
• Secret gist index: https://gist.github.com/kateinoigakukun/ba21c654a675032aa77906877c906e53

How to reproduce:

curl -L -O https://gist.githubusercontent.com/kateinoigakukun/ba21c654a675032aa77906877c906e53/raw/ecb1d747700ea5b879effae0e73e2e40151514ee/781-duplicate-archive-members.zip
unzip 781-duplicate-archive-members.zip
cd 781-duplicate-archive-members
./repro.sh

Environment used to validate these repros:

• Host: macOS 26.5.1 (arm64)
• Toolchain: ~/Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2026-05-27-a.xctoolchain
• TOOLCHAINS=org.swift.64202605271a
• swift --version: Apple Swift version 6.5-dev (LLVM 8f81a64f6a8bcf6, Swift 4d0c97fa5b05711)
• Swift SDK: DEVELOPMENT-SNAPSHOT-2026-05-27-a-wasm32-unknown-wasip1
• Each repro.sh uses the explicit snapshot toolchain above, not the global swift on PATH.

Observed on this environment:

• --build-system native: passes and preserves the duplicate-member archive semantics
• --build-system swiftbuild: produces a corrupted libWrapper.a by expanding the duplicate-member archive and keeping only one common.o definition

[kateinoigakukun]

Verified with the minimum reproducer from the issue comment gist on Linux using the requested snapshot.

Toolchain:

/home/ubuntu/.local/share/swiftly/toolchains/main-snapshot-2026-06-12/usr/bin/swift --version
Swift version 6.5-dev (LLVM 18d2bfb70c14d89, Swift c13d82e5987aecb)
Target: x86_64-unknown-linux-gnu
Build config: +assertions

Swift SDK: swift-DEVELOPMENT-SNAPSHOT-2026-06-12-a_wasm

Workdir: /workspace/swiftpm-swiftbuild-issues/swb-jskit-781/781-duplicate-archive-members

I preserved the original repro.sh and ran a copied script, repro-linux-2026-06-12.sh, with only the Linux/snapshot setup adapted: Linux toolchain path, requested Swift SDK name, Linux SwiftPM SDK sysroot lookup, and a fallback TOOLCHAINS=swift-DEVELOPMENT-SNAPSHOT-2026-06-12-a because this Linux toolchain has no macOS Info.plist.

Command:

TOOLCHAIN=/home/ubuntu/.local/share/swiftly/toolchains/main-snapshot-2026-06-12 \
SWIFT_SDK=swift-DEVELOPMENT-SNAPSHOT-2026-06-12-a_wasm \
SYSROOT=/home/ubuntu/.swiftpm/swift-sdks/swift-DEVELOPMENT-SNAPSHOT-2026-06-12-a_wasm.artifactbundle/swift-DEVELOPMENT-SNAPSHOT-2026-06-12-a_wasm/wasm32-unknown-wasip1/WASI.sdk \
./repro-linux-2026-06-12.sh > repro-run.log 2>&1

Result:

• input archive was regenerated with duplicate members:

common.o
common.o

• native/control path succeeded and preserved the duplicate archive semantics externally:

succeeded: true
native wrapper archive members:
Wrapper.swiftmodule.o
wrap.swift.o
native symbols include unresolved dup_a and dup_b

• --build-system swiftbuild succeeded as a command, but reproduced the archive corruption:

succeeded: true
swiftbuild wrapper archive members:
Wrapper.o
common.o
swiftbuild_dup_symbol_definitions=1

The swiftbuild wrapper archive contains only one common.o; llvm-nm shows only one of the two duplicate object definitions (dup_b in this run), matching the original failure mode.

Conclusion: still reproducible with the requested 2026-06-12 snapshot and SDK. Leaving this issue open.

Logs/artifacts:

• /workspace/swiftpm-swiftbuild-issues/swb-jskit-781/781-duplicate-archive-members/repro-run.log
• /workspace/swiftpm-swiftbuild-issues/swb-jskit-781/781-duplicate-archive-members/native.log
• /workspace/swiftpm-swiftbuild-issues/swb-jskit-781/781-duplicate-archive-members/swiftbuild.log
• /workspace/swiftpm-swiftbuild-issues/swb-jskit-781/781-duplicate-archive-members/.repro-tmp/native-libWrapper.a
• /workspace/swiftpm-swiftbuild-issues/swb-jskit-781/781-duplicate-archive-members/.repro-tmp/swiftbuild-libWrapper.a
• /workspace/swiftpm-swiftbuild-issues/swb-jskit-781/781-duplicate-archive-members/.repro-tmp/native-symbols.txt
• /workspace/swiftpm-swiftbuild-issues/swb-jskit-781/781-duplicate-archive-members/.repro-tmp/swiftbuild-symbols.txt
• /workspace/swiftpm-swiftbuild-issues/swb-jskit-781/781-duplicate-archive-members/adaptation-notes.md

[kateinoigakukun]

swiftlang/swift-package-manager#10229