sergio/hammer
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

selfhost-verify: musl del toolchain con 256 TLS keys en bootstrap-devfs (frente rust)

Browse Source 
El rustc booteado por mrustc agota los pthread keys de musl al correr
("fatal runtime error: out of TLS keys" — gotcha #4 de mrustc issue #388).
Es el musl del TOOLCHAIN (el loader /lib/ld-musl-x86_64.so.1 que toda tool
del rootfs linkea), NO el musl target del 4/4 (recipes/musl.toml, estático,
intacto). Se añade a bootstrap-devfs.sh un paso idempotente que reconstruye
musl 1.2.5 con PTHREAD_KEYS_MAX=256 (sed en limits.h, build gcc lib/libc.so)
y reemplaza el loader (backup .orig128). ABI-compat: gcc/make siguen
corriendo. Seguro para of_tree: el loader runtime de las tools no cambia los
bytes que emiten; el 4/4 es estático contra hammer-musl.

Verificado a mano: run_rustc pasó el punto donde moría (build de libstd
musl) y avanza (27%+).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
sergio
2026-06-15 09:02:59 -04:00
co-authored by Claude Opus 4.8
parent aa31f04486
commit fc8bc906ea
1 changed files with 29 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
scripts/bootstrap-devfs.sh
+29
View File
@@ -152,6 +152,35 @@ else
ok "build tools presentes en el rootfs ($NEEDED)"
fi
# --- 3b. musl del toolchain con PTHREAD_KEYS_MAX=256 (frente rust variante b) --
# El rustc booteado por mrustc (frente rust) agota los pthread keys de musl al correr:
# `fatal runtime error: out of TLS keys, aborting` (musl default PTHREAD_KEYS_MAX=128; es el
# gotcha #4 de mrustc issue #388). Es el musl del TOOLCHAIN — el loader que toda tool del rootfs
# linkea dinámicamente como intérprete (/lib/ld-musl-x86_64.so.1) — NO el musl target del 4/4
# (recipes/musl.toml, estático, intacto). Reconstruimos musl 1.2.5 con 256 keys y reemplazamos el
# loader. ABI-compat (mismo musl 1.2.5): gcc/make/etc. siguen corriendo. Seguro para of_tree: el
# loader runtime de las tools no afecta los bytes que emiten; el 4/4 es estático contra hammer-musl.
# Idempotente: si ya existe el backup .orig128, no rehace nada.
MUSL_LOADER="$ROOTFS/lib/ld-musl-x86_64.so.1"
if [[ $SKIP_APK -eq 0 && ! -f "$MUSL_LOADER.orig128" ]]; then
log "musl: reconstruyendo loader del toolchain con PTHREAD_KEYS_MAX=256 (frente rust)"
MUSL_VER=1.2.5
MUSL_SHA=a9a118bbe84d8764da0ea0d28b3ab3fae8477fc7e4085d90102b8596fc7c75e4
MWORK="$WORK/musl256"; rm -rf "$MWORK"; mkdir -p "$MWORK"
curl -fsSL -o "$MWORK/musl.tar.gz" "https://musl.libc.org/releases/musl-$MUSL_VER.tar.gz"
echo "$MUSL_SHA $MWORK/musl.tar.gz" | sha256sum -c - >/dev/null || die "musl tarball sha256 mismatch"
tar -C "$MWORK" -xzf "$MWORK/musl.tar.gz"
sed -i 's/#define PTHREAD_KEYS_MAX 128/#define PTHREAD_KEYS_MAX 256/' "$MWORK/musl-$MUSL_VER/include/limits.h"
# Build de lib/libc.so (= el loader) dentro del rootfs con gcc (como lo compila Alpine).
bwrap --bind "$ROOTFS" / --bind "$MWORK" /musl256 --proc /proc --dev /dev --tmpfs /tmp \
--setenv PATH /usr/bin:/bin --setenv HOME /tmp --chdir "/musl256/musl-$MUSL_VER" \
sh -c 'CC=gcc ./configure --prefix=/usr >/dev/null && make -j"$(nproc)" lib/libc.so >/dev/null' \
|| die "build de musl-256 falló"
cp -a "$MUSL_LOADER" "$MUSL_LOADER.orig128" # backup del loader Alpine original
cp "$MWORK/musl-$MUSL_VER/lib/libc.so" "$MUSL_LOADER"
ok "musl del toolchain con 256 TLS keys (loader reemplazado; backup en .orig128)"
fi
# --- 4. Resumen ---------------------------------------------------------------
cat <<EOF