From 239e570be0fb8167bbd334d998a21f03c661a478 Mon Sep 17 00:00:00 2001 From: AJ ONeal Date: Wed, 11 Mar 2026 12:19:44 -0600 Subject: [PATCH] =?UTF-8?q?docs:=20answer=20Issue=205=20=E2=80=94=20static?= =?UTF-8?q?=20musl=20libc=20classification=20fix?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ANSWERS.md | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/ANSWERS.md b/ANSWERS.md index 5376fcb..725d51c 100644 --- a/ANSWERS.md +++ b/ANSWERS.md @@ -82,3 +82,24 @@ Already handled correctly on the Go side: This is a Node.js-side issue only — the `host-targets.js` WATERFALL needs `universal2` in the arch fallback chain, similar to what `CompatArches` does. + +## Re: Issue 5 — Static musl builds tagged as `libc='musl'` + +**Fixed.** The Go classifier now detects Rust-style `-unknown-linux-musl` target +triples in `classifyGitHub` and overrides `libc` from `musl` to `none`. + +The fix uses the specific Rust triple pattern, not a blanket musl→none: +- `bat-v0.26.1-x86_64-unknown-linux-musl.tar.gz` → `libc='none'` (static) +- `powershell-7.5.4-linux-musl-x64.tar.gz` → `libc='musl'` (hard dependency) +- `bun-linux-x64-musl.zip` → `libc='musl'` (hard dependency) +- `node-v20.2.0-linux-x64-musl.tar.gz` → `libc='musl'` (hard dependency) + +The `classify.Filename()` function still returns `LibcMusl` for any filename +containing "musl" at a word boundary. The override happens in `classifypkg` +where we have enough context to distinguish static from dynamic musl linking. + +Your WATERFALL workaround (`['none', 'gnu', 'musl', 'libc']`) is still useful +for the Node.js side — it makes glibc hosts fall through to musl builds when +no gnu or static build is available. But with this fix, the Go cache correctly +tags Rust musl builds as `none`, so glibc hosts find them in the `none` slot +without needing the musl fallback.