Solution to issue cannot be found in the documentation.
Issue
When statically linking against libpython3.12.a (from libpython-static 3.12.12, conda‑forge), the final link step fails with:
.../lib/libpython3.12.a(pystrtod.o): in function `memset':
.../sysroot/usr/include/bits/string3.h:81:(.text.hot.PyOS_double_to_string+0x1b0):
undefined reference to `__warn_memset_zero_len'
collect2: error: ld returned 1 exit status
This is a FORTIFY header diagnostic that should have been optimized away at compile time. The __warn_memset_zero_len symbol is intentionally not provided by glibc at link/run time. If the reference survives into a static object, static linking fails (rare but known behavior of older FORTIFY header paths).
Why this looks like a packaging/toolchain regression
- With Python 3.12.11 (conda‑forge) + GCC 13.3, the exact same code path only produced a linker warning memset used with constant zero length parameter and produced a working binary. (We have a working build log that shows the warning from bits/string3.h.)
- After upgrading to Python 3.12.12 (conda‑forge) together with conda GCC 14.3 + Binutils 2.44 and sysroot_linux-64=2.28, the same build now fails in the final link step with an undefined reference to __warn_memset_zero_len. The environment/lockfiles and install logs confirm the toolchain (GCC 14.3, Binutils 2.44, sysroot 2.28).
Environment (minimal relevant pieces)
- Platform: linux-64
- libpython-static: 3.12.12 (conda‑forge)
- Toolchain: gcc_impl_linux-64=14.3.0, binutils_impl_linux-64=2.44, ld_impl_linux-64=2.44, gcc_linux-64=14.3.0 (depends on sysroot_linux-64)
- Sysroot: sysroot_linux-64=2.28 (via toolchain deps)
- Flags (from link logs): -D_FORTIFY_SOURCE=2 -O2 ... (inherited by SCons/conda compilers)
How to Reproduce
# 1) Fresh env with conda-forge toolchain & python 3.12.12
micromamba create -n repro -c conda-forge python=3.12.12 libpython-static=3.12.12 gcc_linux-64=14.3 binutils=2.44 -y
micromamba activate repro
# 2) Minimal embed to force link against the static libpython
cat > test.c <<'EOF'
#include <Python.h>
int main(void) {
Py_Initialize();
Py_Finalize();
return 0;
}
EOF
# 3) Try to link statically against libpython3.12.a (note: adjust paths if needed)
x86_64-conda-linux-gnu-cc -O2 -D_FORTIFY_SOURCE=2 -I"$CONDA_PREFIX/include/python3.12" \
test.c "$CONDA_PREFIX/lib/libpython3.12.a" -lpthread -ldl -lm -lutil -o test
# Expected: links fine
# Actual: undefined reference to `__warn_memset_zero_len` from .../pystrtod.o → link failsInstalled packages
Name Version Build Channel
───────────────────────────────────────────────────────────────────────
_libgcc_mutex 0.1 conda_forge conda-forge
_openmp_mutex 4.5 2_gnu conda-forge
binutils 2.44 h4852527_4 conda-forge
binutils_impl_linux-64 2.44 h9d8b0ac_4 conda-forge
binutils_linux-64 2.44 h4852527_4 conda-forge
bzip2 1.0.8 hda65f42_8 conda-forge
ca-certificates 2025.10.5 hbd8a1cb_0 conda-forge
gcc_impl_linux-64 14.3.0 hd9e9e21_7 conda-forge
gcc_linux-64 14.3.0 h298d278_12 conda-forge
icu 75.1 he02047a_0 conda-forge
kernel-headers_linux-64 4.18.0 he073ed8_8 conda-forge
ld_impl_linux-64 2.44 h1aa0949_4 conda-forge
libexpat 2.7.1 hecca717_0 conda-forge
libffi 3.5.2 h9ec8514_0 conda-forge
libgcc 15.2.0 h767d61c_7 conda-forge
libgcc-devel_linux-64 14.3.0 h85bb3a7_107 conda-forge
libgcc-ng 15.2.0 h69a702a_7 conda-forge
libgomp 15.2.0 h767d61c_7 conda-forge
liblzma 5.8.1 hb9d3cd8_2 conda-forge
libnsl 2.0.1 hb9d3cd8_1 conda-forge
libpython-static 3.12.12 hecca717_1_cpython conda-forge
libsanitizer 14.3.0 hd08acf3_7 conda-forge
libsqlite 3.51.0 hee844dc_0 conda-forge
libstdcxx 15.2.0 h8f9b012_7 conda-forge
libstdcxx-ng 15.2.0 h4852527_7 conda-forge
libuuid 2.41.2 he9a06e4_0 conda-forge
libxcrypt 4.4.36 hd590300_1 conda-forge
libzlib 1.3.1 hb9d3cd8_2 conda-forge
ncurses 6.5 h2d0b736_3 conda-forge
openssl 3.5.4 h26f9b46_0 conda-forge
pip 25.2 pyh8b19718_0 conda-forge
python 3.12.12 hd63d673_1_cpython conda-forge
readline 8.2 h8c095d6_2 conda-forge
setuptools 80.9.0 pyhff2d567_0 conda-forge
sysroot_linux-64 2.28 h4ee821c_8 conda-forge
tk 8.6.13 noxft_hd72426e_102 conda-forge
tzdata 2025b h78e105d_0 conda-forge
wheel 0.45.1 pyhd8ed1ab_1 conda-forge
zstd 1.5.7 hb8e6e7a_2 conda-forge
Environment info
libmamba version : 2.3.3
micromamba version : 2.3.3
curl version : libcurl/8.14.1 OpenSSL/3.5.4 zlib/1.3.1 zstd/1.5.7 libssh2/1.11.1 nghttp2/1.67.0
libarchive version : libarchive 3.8.2 zlib/1.3.1 bz2lib/1.0.8 libzstd/1.5.7 libb2/bundled
envs directories : /home/gitlab-runner/micromamba/envs
package cache : /home/gitlab-runner/micromamba/pkgs
/home/gitlab-runner/.mamba/pkgs
environment : repro (active)
env location : /home/gitlab-runner/micromamba/envs/repro
user config files : /home/gitlab-runner/.mambarc
populated config files : /home/gitlab-runner/.condarc
virtual packages : __unix=0=0
__linux=5.4.0=0
__glibc=2.31=0
__archspec=1=x86_64_v4
channels : https://conda.anaconda.org/nodefaults/linux-64
https://conda.anaconda.org/nodefaults/noarch
base environment : /home/gitlab-runner/micromamba
platform : linux-64
Solution to issue cannot be found in the documentation.
Issue
When statically linking against libpython3.12.a (from libpython-static 3.12.12, conda‑forge), the final link step fails with:
This is a FORTIFY header diagnostic that should have been optimized away at compile time. The __warn_memset_zero_len symbol is intentionally not provided by glibc at link/run time. If the reference survives into a static object, static linking fails (rare but known behavior of older FORTIFY header paths).
Why this looks like a packaging/toolchain regression
Environment (minimal relevant pieces)
How to Reproduce
Installed packages
Environment info