fix-elf: patchelf PT_INTERP to strip +brewing post-install

[tannevaled]

Summary

brewkit installs each pkg to ${prefix}+brewing/ then renames to ${prefix}/. The build's ld --dynamic-linker=...+brewing/.../ld-linux*.so flag bakes the +brewing path into PT_INTERP of every linked binary. fix-elf has historically only patched RPATH via patchelf, leaving PT_INTERP referencing a path that no longer exists post-rename.

This is harmless for typical pantry recipes — their binaries' PT_INTERP points at the host runner's /lib(64)?/ld-linux-*.so, never back into the bottle. So the +brewing substring never appears in PT_INTERP and there's nothing to fix.

For low-level packages whose own bottle ships ld-linux* (glibc is the obvious example, future musl bottle would be another), PT_INTERP after install is broken — bin/ld.so, bin/getconf, bin/iconv etc. all fail to exec because the kernel can't find the +brewing path. This blocks any direct invocation of the bottle's tools in the test phase or by consumers.

Change

Add a no-op-by-default fix_interpreter() step alongside set_rpaths():

export default async function fix_rpaths(installation: Installation, pkgs: string[]) {
  console.info("doing SLOW rpath fixes…")
  for await (const [exename] of exefiles(installation.path)) {
    await set_rpaths(exename, pkgs, installation)
    await fix_interpreter(exename)   // ← new
  }
}

fix_interpreter():

• reads PT_INTERP with patchelf --print-interpreter
• if it contains "+brewing", rewrites via patchelf --set-interpreter
• skips if the rewritten target doesn't exist (guards against bad rewrites)
• catches errors quietly when the file is statically linked / has no .interp section (consistent with the existing set_rpaths defensive style)

Compatibility

No behaviour change for any existing pantry bottle. They all consume the host runner's ld-linux at PT_INTERP, so the substring "+brewing" never matches and fix_interpreter() is a no-op.

Refs

• feat(gnu.org/glibc): host-independent recipe, 9 versions × 2 arches incl. HPC 2.17 / 2.24 pantry#12968 (gnu.org/glibc PR) — the use case that surfaced this gap. The PR currently works around it with a bash-builtin file-existence test instead of running the bottle's own ld.so --version / getconf --version. With this brewkit change merged, that workaround can be dropped.
• New/gnu.org/glibc pantry#5080 (mxcl's Feb 2024 glibc attempt — same gap, never resolved).

🤖 Generated with Claude Code

[Copilot]

Copilot wasn't able to review any files in this pull request.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[jhheider]

this might be more robust if it used lib/config.ts for config.path.build_install; I don't know if that introduces more difficulties. fix-machos.rb specifically doesn't, since it's in Ruby.

[jhheider]

hm, this path isn't fixed and absolute, though. it's relative to PKGX_DIR...

[jhheider]

Codex suggests:

• Do not patch PT_INTERP to pkgx-managed glibc by default.

• For glibc package self-tests, explicitly invoke its loader:
  {{prefix}}/lib/ld-linux-.so. --library-path {{prefix}}/lib .

• If a package truly needs hermetic glibc, use wrapper scripts, not PT_INTERP.

• If fix-elf touches PT_INTERP, restrict it to replacing +brewing only when the final path is guaranteed stable in that install context, not as general bottle metadata.

• Hermetic binary: use a wrapper:

  exec "$prefix/lib/ld-linux-x86-64.so.2"
  --library-path "$prefix/lib:$other_libs"
  "$prefix/libexec/foo" "$@"
  The inner ELF can even have a dummy/system PT_INTERP; the wrapper explicitly invokes the loader.

[tannevaled]

Thanks @jhheider and @codex — you're both right, and I'm going to withdraw this PR.

Why withdraw

The core insight from Codex's review:

Do not patch PT_INTERP to pkgx-managed glibc by default. For glibc package self-tests, explicitly invoke its loader: {{prefix}}/lib/ld-linux-*.so.* --library-path {{prefix}}/lib <binary>. If a package truly needs hermetic glibc, use wrapper scripts, not PT_INTERP.

I've now done exactly that in pkgxdev/pantry#12968's test block — the glibc bottle's test compiles test.c and runs it via the bottle's loader explicitly:

"$LIBDIR/$LDSO" --library-path "$LIBDIR" ./test-bottle

…which proves the bottle's libc + ld.so + headers form a self-consistent set, without needing brewkit to patch PT_INTERP. So the original motivation for this PR (test-time PT_INTERP rewriting) is gone — that part of the problem is better solved at the recipe-test level.

The deeper question — should brewkit ship hermetic binaries?

For runtime hermeticity (binary always uses the bundled glibc regardless of host), Codex's wrapper-script pattern is the right shape:

exec "$prefix/lib/ld-linux-*.so.*" \
  --library-path "$prefix/lib:$other_libs" \
  "$prefix/libexec/foo" "$@"

That's an orthogonal feature that should land as a separate brewkit issue/PR — it's "how does brewkit produce hermetic bottles," not "how does fix-elf rewrite PT_INTERP." Happy to open that follow-up if there's appetite (probably belongs in lib/porcelain/ alongside bottle.ts, not in fix-elf.ts).

Closing this PR. Apologies for the spin-up.

[jhheider]

Never a problem. One option is a brewkit helper to use hermetic glibc, similar to bkpyvenv or fix-shebang.ts. Then, if you need hermetic glibc, you move all of bin to libexec and create hermetic wrappers and depend explicitly (or you get 2.17 by default).