glibc: the relocation neither relocated nor left the file intact — and the seven rules

[Sunrisepeak]

Chain: openxlings/libxpkg#35 → mcpplibs/mcpp-index#164 → openxlings/xlings#488 → this.

The ldd we ship does not survive bash -n

glibc's tarball is a prebuilt, so it carries the absolute paths of the machine that built it — a machine still on the .xlings_data home layout xlings abandoned long ago, so those paths cannot exist anywhere. The recipe knew this and had a rewrite for it. Measured on the payload on disk, that rewrite was wrong three ways at once and reported success every time.

It named six files. Five files hold build paths; four of the five are on that list and were processed wrongly, and the fifth was never opened.

Its pattern ran leftward through quotes and variable names. ([^%s)]+)/<marker>/lib swallowed RTLDLIST=" along with the path:

# what upstream ships
RTLDLIST="/p/lib/ld-linux.so.2 /p/lib64/ld-linux-x86-64.so.2 /p/libx32/ld-linux-x32.so.2"

# what we ship
./ld-linux.so.2 .64/ld-linux-x86-64.so.2 .x32/ld-linux-x32.so.2"

bash -n on ~/.xlings/data/xpkgs/xim-x-glibc/2.39/bin/ldd fails at line 38. 2.44 too. It has been shipping like that.

Its tail was anchored at /lib, so TEXTDOMAINDIR=<build>/share/locale in the same file was untouched — the build path stayed in the artifact, which was the only thing the code existed to remove. (/libx32 matching /lib plus a leftover x32 is where .x32/ came from.)

And it wrote if it had substituted anything and called that success, so "still has build paths" and "we corrupted the file" both produced exactly the output of a clean run: nothing.

Now delegated to elfpatch.relocate_build_paths (libxpkg 0.0.51), which enumerates the payload, anchors on a whole absolute path token, and asserts the result.

Verified end to end against a slice of a real home

	before	after
files with build paths	5	0
bash -n bin/ldd	fails at line 38	passes
libc.so GROUP	./libc.so.6	names real files
ldd <payload binary>	does not run	prints resolved addresses

The capability is probed with type(), not truthiness — an unknown field on a module proxy is truthy on every client, a trap this repo has hit twice. On an older xlings the recipe rewrites only the linker scripts, where the greedy pattern had nothing to swallow, and says plainly what is left undone. It no longer corrupts bin/: an ldd naming a directory that does not exist is strictly better than an ldd bash cannot parse.

The seven rules, each with a criterion that can be run

They existed only in xlings design documents, which is where rules go to be agreed with and not applied. Normative text now, in the spec recipes are written against.

R3's criterion, for instance: if a fix ADDS a path rather than REMOVING one it is a workaround — libxpkg 0.0.49 fails that test and 0.0.50 passes it, and neither needed an opinion to decide. Every rule is anchored to a defect that shipped: deps_exports for R1, libxpkg 0.0.49 for R3, this glibc relocation for R4, elfpatch._find_tool for R6, the nvidia dependency table for R7.

Two additions:

• Contract text may not say "if X is absent, fall back to Y". That one sentence authorises every reader to implement its own Y, so the number of answerers grows with the number of readers.
• A subos.env declaration of a variable that can load code into a process is a privileged operation and must say why RPATH cannot serve the same need. There is exactly one honest answer, and 2026.8.6.1: three places a view answered a question the payload owns, and the subos layer's one live version xlings#488's gate verification narrowed it: the object that calls dlopen is the host's own file, which we cannot patch.

Audited the existing spec text against the new rule — the mirror "fallback" wording is a retry over byte-identical sources, and binding defaulting to the declaring package is applied by the writer. Neither is a violation.

Tests

pytest tests/ -m static — 743 passed.