The old `postInstall` was ugly, and made for a needlessly course-grained
package. This makes more smaller derivations, and ones that additionally
can be built in parallel.
Now that we assemble the source code per each package in a separate prep
derivation since b6727bbeac, we don't need
rsync in the package proper derivations.
I realized what rhelmot did in 61202561d9
(specify what packages just need `stdenvNoLibc`) is definitely the right
approach for this, and adjusted NetBSD and OpenBSD to likewise use it.
With that change, we don't need these confusing and ugly `*bsdCross`
package sets at all!
We can get rid of a lot more libc-related `*Cross`, and I will do so
soon, but this is the first step.
(adapted from commit 51f1ecaa59)
For a long time, we've had `crossLibcStdenv`, `*Cross` libc attributes,
and `*bsdCross` pre-libc package sets. This was always bad because
having "cross" things is "not declarative": the naming doesn't reflect
what packages *need* but rather how we *provide* something. This is
ugly, and creates needless friction between cross and native building.
Now, almost all of these `*Cross` attributes are gone: just these are
kept:
- Glibc's and Musl's are kept, because those packages are widely used
and I didn't want to risk changing the native builds of those at this
time.
- generic `libcCross`, `theadsCross`, and friends, because these relate
to the convolulted GCC bootstrap which still needs to be redone.
The BSD and obscure Linux or freestnanding libcs have conversely all
been made to use a new `stdenvNoLibc`, which is like the old
`crossLibcStdenv` except:
1. It usable for native and cross alike
2. It named according to what it *is* ("a standard environment without
libc but with a C compiler"), rather than some non-compositional
jargon ("the stdenv used for building libc when cross compiling",
yuck).
I should have done this change long ago, but I was stymied because of
"infinite recursions". The problem was that in too many cases we are
overriding `stdenv` to *remove* things we don't need, and this risks
cyles since those more minimal stdenvs are used to build things in the
more maximal stdenvs.
The solution is to pass `stage.nix` `stdenvNoCC`, so we can override to
*build up* rather than *tear down*. For now, the full `stdenv` is also
passed, so I don't need to change the native bootstraps, but I can see
this changing as we make things more uniform and clean those up.
Finally, the BSDs also had to be cleaned up, since they have a few
pre-libc dependencies, demanding a systematic approach. I realized what
rhelmot did in 61202561d9 (specify what
packages just need `stdenvNoLibc`) is definitely the right approach for
this, and adjusted NetBSD and OpenBSD to likewise use it.
The big `fetchCVS` is slow, but a one-time cost. Everything else is much
faster, and not having to manage a gazillion `version` and `sha256`
fields is much easier.
This brings NetBSD in line with how we do FreeBSD and OpenBSD.
These headers conflict with the unwind headers from libunwind
provided by libgcc_eh in `freebsd.libc`.
Upstream FreeBSD does not use these headers in any capacity,
and they cause some incompatibilities since libcxxrt unwind.h
requires _GNU_SOURCE for some functions, while libunwind does not.
Previously, an attribute named isStatic did this, but this was lost in a
refactor. Revive it and rename it to noLibc to be more clear about its
intended use.
netbsd can no longer compile under FreeBSD native early bootstrap
stdenv, so switch to coreutils. This only involves discarding the -l
flag. The -l flag causes a symlink instead of a copy to be installed, so
it is safe to discard during bootstrap.
This package will be necessary down the line for binary patching
applications built for non-nix FreeBSD. It is additionally being
considered for inclusion in FreeBSD libcxx, both cross and native.
