I was able to successfully compile a hello world program (without setting a sysroot for now). But it was using a new libc. And looking into the image I found this file: /usr/lib32/libc-2.31.so. Shouldn't that be 2.20?

No, the sysroot is elsewhere (/x-tools/), not in /usr/

I'm not sure what went wrong with zig, as for the attempt to borrow the sysroot from the target, not going to delve into it :3

I don't use cross myself, but have plenty of experience with cross-compilation via cargo-zigbuild with sysroots managed via Fedora dnf's --installroot + --forcearch options, then updating some ENV to reference those when building.

Zig makes targeting lower glibc (or specific release) pretty straight-forward, but when you should also keep in mind situations where your build will link to libs in it's search path, and that differs from runtime resolving of deps.

For example I can build for aarch64 on an x86_64 host with a custom sysroot that works well. However when I try to inspect the deps on that same system with ldd (more specifically the aarch64 version in the sysroot)

• It will now use runtime search paths, where /etc/ld.so.cache + LD_LIBRARY_PATH are relevant.
• As the binary likely only has the library name to resolve, in this scenario it will attempt to resolve from the x86_64 root, not the sysroot as it knows nothing about that (and really shouldn't for distribution).
• If I take that binary and use ldd from within a chroot of that sysroot, or on a aarch64 host, then it'll resolve to the correct library paths.

In some cases you may want to link to libraries that are not part of the host system, but bundled with your binary for distribution. These can be linked to by having your binary built (or in post via tools like patchelf) configure RPATH / RUNPATH with $ORIGIN (not an ENV but special keyword string) as the base relative path from the binary, libraries will then resolve as expected for RPATH which will apply that prefix recursively, while RUNPATH will need to be applied to each individual library you bundle otherwise the transitive deps will fallback to resolving elsewhere instead as they'd no longer be away of the RUNPATH (RPATH is deprecated, but provides such functionality). LD_LIBRARY_PATH is used for resolution after RPATH and before RUNPATH, the behaviour also differs on Alpine / musl, where RPATH and RUNPATH are treated the same IIRC (effectively like LD_LIBRARY_PATH but encoded into the binary/library).

From other information you shared it sounds like you were trying to build static glibc? This is generally discouraged as it's not proper static like musl.

• In some cases you can use Eyra instead (requires nightly Rust toolchain and may not be compatible with some foreign source deps depending on the glibc symbols).
• You can control the external libs for a portable build without fully static linking glibc, by using RPATH/RUNPATH as mentioned. If your linked deps aren't that many, this is viable should you need to resort to this. It would be independent of the host system, so you could run such on Alpine for example as there should be no linking to any libraries provided by the system itself.
• Ideally with Zig it should work just fine if you lower the glibc target for compatibility, but make sure you are providing the correct sysroot for any header includes needed, along with explicit search path (eg: RUSTFLAGS='-L <your sysroot path>/usr/lib64') for that sysroot (Zig excludes these for cross-compilation and cargo-zigbuild also forces -nostdinc so adjusting sysroot alone probably won't be sufficient). You may need to additionally set other ENV when relevant like the PKG_CONFIG_SYSROOT_DIR or CFLAGS='-isystem <your sysroot path>/usr/include', etc.

Oh and Zig doesn't support static glibc, it will segfault in earlier releases and fail/error on the current 14 series IIRC, but it is being enabled as a supported option with Zig 15 but not for non-native/custom targets which includes targeting different glibc than system IIRC, cargo-zigbuild also needs to make a change to support this once available AFAIK.