swiftwasm / swiftwasm/JavaScriptKit
[SwiftBuild] Preserve duplicate archive members when SwiftBuild expands static archives for linking
Nadie ha tomado este issue todavía.
- Lenguaje dominante
- Swift
- Estrellas
- 986
- Forks
- 76
- Merge medio
- 21 h 11 min
- PR fusionados (30 d)
- 4
Descripción
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
Guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Línea de trabajo
Comienza descomprimiendo el reproductor enlazado y ejecutando repro-linux-2026-06-12.sh, o repro.sh en macOS; después compara los miembros de archivo nativos y de SwiftBuild con llvm-ar y los símbolos con llvm-nm. Rastrea la ruta de expansión de archivos de SwiftBuild responsable de la salida diferente; se considera terminado cuando ambos miembros duplicados sobreviven a la preparación y los productos wasm finales se enlazan con dup_a y dup_b presentes.
Escrito por el modelo de indexación a partir del texto del issue.
Evaluación
- Stack tecnológico
- swift, wasm
- Área
- build-system
- Tipo de issue
- Error
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Estado de actividad
- Tranquilo
- Claridad
- Bastante claro
- Aptitud para principiantes
- 48/100