Bug report
Bug description:
This appears to be a regression: in our static musl packaging, Python 3.13 built successfully, but failures started in 3.14 and are still present in 3.15.0a7.
When building CPython 3.15.0a7 as a fully static musl target, final linking of python and Programs/_testembed fails with duplicate _Py_LibHacl_* symbols.
The link command includes several Modules/_hacl/*.o files twice, then ld reports multiple definitions for symbols from those objects.
I know x86_64-unknown-linux-musl is not a PEP 11 supported tier, but this looks like a generic linker-input duplication issue in the HACL link flags (similar class to #133042), not musl-specific behavior.
Reproduction:
I’m reproducing this from nixpkgs static Python packaging, but the relevant configure mode is:
./configure \
--disable-shared \
--enable-static \
--host=x86_64-unknown-linux-musl \
--build=x86_64-unknown-linux-gnu \
--with-lto \
LDFLAGS=-static \
MODULE_BUILDTYPE=static \
ac_cv_func_dlopen=no
make -j
Build fails while linking python and Programs/_testembed.
Evidence from build log:
Configure/version context:
- source: Python-3.15.0a7
- host: x86_64-unknown-linux-musl
- compiler: x86_64-unknown-linux-musl-gcc
- static build mode: --enable-static --disable-shared LDFLAGS=-static MODULE_BUILDTYPE=static
In both -o python and -o Programs/_testembed link commands, these appear twice:
Modules/_hacl/Hacl_Hash_MD5.o
Modules/_hacl/Hacl_Hash_SHA1.o
Modules/_hacl/Hacl_Hash_SHA2.o
Modules/_hacl/Hacl_Hash_SHA3.o
Modules/_hacl/Hacl_Hash_Blake2s.o
Modules/_hacl/Hacl_Hash_Blake2b.o
Modules/_hacl/Lib_Memzero0.o
Modules/_hacl/Hacl_Hash_Blake2s_Simd128.o
Modules/_hacl/Hacl_Hash_Blake2b_Simd256.o
Object count summary from the -o python line:
- total HACL objects passed: 20
- unique HACL objects: 11
- 9 hash/memzero objects are each passed exactly twice
- Hacl_HMAC.o and Hacl_Streaming_HMAC.o appear once
Example linker failures:
ld: Modules/_hacl/Hacl_Hash_MD5.o: multiple definition of `_Py_LibHacl_Hacl_Hash_MD5_init'; ... first defined here
ld: Modules/_hacl/Hacl_Hash_SHA1.o: multiple definition of `_Py_LibHacl_Hacl_Hash_SHA1_init'; ... first defined here
...
collect2: error: ld returned 1 exit status
make: *** [Makefile:1151: python] Error 1
make: *** [Makefile:1841: Programs/_testembed] Error 1
Expected behavior:
Static builds should not duplicate identical HACL object files on the final link line for python / _testembed.
Related issues/PRs:
If useful, I can attach the full failing link command and full build log.
Note: This report was prepared with the help of Codex.
Linked PRs
Bug report
Bug description:
This appears to be a regression: in our static musl packaging, Python 3.13 built successfully, but failures started in 3.14 and are still present in 3.15.0a7.
When building CPython 3.15.0a7 as a fully static musl target, final linking of python and Programs/_testembed fails with duplicate _Py_LibHacl_* symbols.
The link command includes several Modules/_hacl/*.o files twice, then ld reports multiple definitions for symbols from those objects.
I know x86_64-unknown-linux-musl is not a PEP 11 supported tier, but this looks like a generic linker-input duplication issue in the HACL link flags (similar class to #133042), not musl-specific behavior.
Reproduction:
I’m reproducing this from nixpkgs static Python packaging, but the relevant configure mode is:
Build fails while linking python and Programs/_testembed.
Evidence from build log:
Configure/version context:
In both -o python and -o Programs/_testembed link commands, these appear twice:
Object count summary from the -o python line:
Example linker failures:
Expected behavior:
Static builds should not duplicate identical HACL object files on the final link line for python / _testembed.
Related issues/PRs:
If useful, I can attach the full failing link command and full build log.
Note: This report was prepared with the help of Codex.
Linked PRs