fix(gnu.org/gcc): add libc-wrapper for end-user pkgx gcc (#8423)

[tannevaled]

Summary

Adds a thin POSIX-sh wrapper at {{prefix}}/bin/<tool> (gcc, g++, cpp, c++, gfortran) that injects -isystem $glibc/include -L$glibc/lib for end-user invocations, without poisoning gcc's own bootstrap build. The real binaries are moved to {{prefix}}/libexec/gcc-wrap/. Adds gnu.org/glibc: '<2.38' + kernel.org/linux-headers: '*' as Linux deps so pkgx provisions a sibling glibc bottle the wrapper can find.

Why this approach

Previous attempts at #8423:

• fix(gnu.org/gcc): wire libc + linux-headers (closes #8423) #13084 (runtime.env CPATH): clobbered brewkit's composed CPATH during gcc's own build → couldn't find gmp.h. Closed.
• fix(gnu.org/gcc): bottle the libc via --with-sysroot (addresses #8423) #13092 (--with-sysroot): configure-time test programs link against the bottled glibc's interp path which doesn't exist on the host → cannot run C++ compiled programs. Closed.

This take avoids both pitfalls because the wrapper:

• is only added to the FINAL installed gcc (no build-time poisoning)
• NO-OPs when CPATH is already set (brewkit build context — guards future bootstrap loops)
• resolves the sibling glibc bottle path lazily via $0-relative lookup, not via baked-in configure flags
• pins glibc <2.38 to avoid C23 symbol redirects (__isoc23_*) absent on older runners

Pattern is modeled on the bklibcvenv shim (brewkit#348).

Pairs with

• fix(gnu.org/gcc): add Debian multi-arch triplet symlinks (addresses #8423) #13083 (multi-arch triplet symlinks). Together: full close of Inconsistencies with dnf/apt install gcc #8423.

Test plan

• CI builds gcc on linux/x86-64 + linux/aarch64 (cross + native)
• Verify pkgx gcc -E -x c /dev/null succeeds without distro glibc-devel
• On a stock Fedora rootfs without glibc-devel, pkgx gcc test.c -o test && ./test succeeds
• pkgx +gnu.org/gcc cc -v 2>&1 | grep gnu.org/glibc confirms the wrapper found the bottle
• Bootstrap of gcc from a wrapped gcc (next gcc version build) doesn't double-inject
• Darwin build unchanged (wrapper guarded by if: linux)

🤖 Generated with Claude Code

[jhheider]

should this be re-evaluated in light of the changes (thin loader shim in zig) to bklibcvenv? the shims had the problem of messing with $0, which the loader doesn't. we should also ensure we test that we've done what we expected.

[tannevaled]

Reworked per your review:

• No more $0 muxing. Instead of one shared shim that infers which compiler it stands in for from basename "$0", I now generate one wrapper per tool (gcc/g++/cpp/c++/gfortran) with the target + c++-ness baked in at install time. The shim locates itself by canonicalizing $0 through symlinks (readlink -f, the sh analogue of /proc/self/exe) — so triplet-symlink and even external-symlink invocations resolve to the right target. The real driver stays in bin/ as .<tool>-real so gcc's own cc1/cc1plus/collect2 lookup keeps working.
• A real test (linux): with a sibling gnu.org/glibc bottle, gcc/g++ compile+link+run, and the produced binary's PT_INTERP is asserted to be the bottle's ld.so; plus a negative check that with CPATH set the wrapper no-ops back to host libc.

While writing the test I also caught a latent bug in the original wrapper: the pkgx glibc bottle keeps crt*.o/libc.so.6/ld-linux* in a versioned sub-libdir (lib/glibc-X.Y), not lib/, so the old -L$libc/lib + ls $libc/lib/ld-linux* found nothing. Fixed (locate via libc.so.6, add -B + the libstdc++/libgcc_s rpath).

Validated end-to-end on real x86_64 hardware (C, C++ <vector>, gfortran, triplet- and external-symlink invocations all produce pkgx-glibc binaries that run; CPATH-set + no-sibling both fall back to host). CI is the final confirmation of the brewkit sibling-layout assumption.