This replaces the mess of buildEnvs with a single Rust binary that
spits out a mostly-complete root filesystem for an fhsenv.
The main goal is to have includeClosures, as we want all of the
dependencies to be in the fhsenv to avoid Steam's (and others')
LD_LIBRARY_PATH shenanigans, but without 32-bit libraries leaking
into lib64 when a 64-bit package like mangohud depends on a 32-bit
version of itself.
We "fix" this by actually looking at the files and explicitly moving
32-bit stuff to $out/lib32. This could be avoided if we had recursive
Nix, or at least system info in exportReferencesGraph, but alas.
For some reason this also shrinks the fhsenvs massively, even though
there's currently no layout optimization (e.g. a package with paths
like lib/foo/{bar,baz} will produce two symlinks in the output, even
when it's more optimal to symlink lib/foo to $out/lib/foo directly).
Originally, we switched to bsdtar from libarchive to solve a reproducibility issue related to hardlinks
As of gnu cpio 2.14 the --ignore-dirnlink option is introduced and now included in --reproducible, which solves this issue
By switching back, we are in turn solving an issue in libarchive >=3.7.5 erroring out with "Error reading archive -: (null)"
Change-Id: Ib6140d599b6547d8e941b0251ce996e303c41fa6
514b00cf08 exposed another bug in the
existing wrapper logic: Darwin SDK variables are only exported by
the SDK package hook, so if those variables aren’t already exported
inside the wrappers, the modified versions are not passed down to the
compiler tools, breaking the fallback SDK logic. This was previously
partially masked by passing down a normally‐redundant `-isysroot`
to the compiler, but now we fix it at the source.
This broke e.g. running `clang(1)` without any environment, something
the GHC binary package `installCheckPhase` does indirectly to verify
that there’s nothing missing from the wrapped GHC `$PATH`. It may
also have caused issues building for the build platform inside a
Darwin‐to‐non‐Darwin cross‐compilation build.
`-L` and `-I` are interpreted relative to the `$SDKROOT` by the
Darwin toolchain, so we have to avoid filtering out such paths in the
purity filter hacks in order to not break e.g. the .NET Core build
system. It’s also just the correct thing to do for the platform.
This reduces code duplication, makes the SDK variables available
earlier in the wrappers, and makes the behaviour between the two
wrappers more consistent.
This is basically harmless for the same reason as it is for Clang, and
lets us avoid doing wrapper hacks to fix things like the .NET build.
This reverts commit 4340a5addb.
Now that ld.so is symlinked into the libc derivation,
we can use it as a dynamic linker.
In my testing, OpenBSD does not have any issues with executing from
a symlinked ld.so.
