The explanation for the conditional introduced by
61d9f201ba is longer than a reasonable
inline comment should be. It directed the reader to use `git blame`,
but that tends to bitrot. Let's point the user to a specific nixpkgs
git hash.
This commit cannot be squashed into the previous commit, because a
commit cannot mention its own commit-hash (without performaing an
expensive double-sha1 preimage attack, of course).
boost-context changed its name for mips from "mips1" to "mips" in this
commit:
6edc8184a7
however the native-build code to detect the local architecture still
reports "mips1":
67c074b249/boostcpp.jam (L637)
Therefore native builds of boost-context on mips must specify
architecture= explicitly; without this you will get link failures
"undefined reference to `jump_fcontext`" in code that uses
boost-context.
Currently the "cross compile" codepath, which provides explicit
architecture/abi/address-model/binary-format/os parameters, is
prefixed by this comment:
```
# TODO: make this unconditional
```
This commit does so, at least if `isMips`.
This commit is needed in order for native builds of nix to succeed on
mips.
This commit makes two changes:
1. Boost changed its taxonomy for architecture names between the 1.77 and
1.78 releases, in this commit:
6edc8184a7
2. During the review of #161162 I [was asked about][1] the source of
the [mips64-context.patch][2] that I had included in the original
version of the PR. I searched through the boost-context revision
history and found [a nearly identical patch][3], which I
substituted in the final, merged version of the PR.
As it turns out, my [mips64-context.patch][2] was an earlier
revision of what was eventually accepted to boost-context. The
only difference between the two patches is the name they use:
mips64 vs mips1.
When switching to the accepted version of the boost patch, I should
have also updated libraries/boost/generic.nix to change mips64 to
mips1. This commit does that.
[1]: https://github.com/NixOS/nixpkgs/pull/161162#discussion_r847903087
[2]: https://raw.githubusercontent.com/a-m-joseph/nixpkgs/1ca5025945470ce96408552b9117674b12efaf04/pkgs/development/libraries/boost/mips64-context.patch
[3]: e3f744a186.patch
Prior needsUserConfig setting is unconditionally applied for darwin.
This is not valid for static builds and should only be set for dynamically linked darwin builds.
To quote the release-notes[1]:
> When _DYNAMIC_STACK_SIZE_SOURCE or _GNU_SOURCE are defined,
> PTHREAD_STACK_MIN is no longer constant and is redefined to
> sysconf(_SC_THREAD_STACK_MIN). This supports dynamic sized register
> sets for modern architectural features like Arm SVE.
This basically means that if the above applies, `#if PTHREAD_STACK_MIN > 0`
won't compile anymore because `PTHREAD_STACK_MIN` isn't a hard-coded
number, but `__sysconf (__SC_THREAD_STACK_MIN_VALUE)`[2].
The issue (for 1.69, 1.70, 1.72 - the other versions seem OK) was
reported upstream, but only for Solaris[3], however the corresponding
patches[4] seem to work as well for us.
Failing Hydra build: https://hydra.nixos.org/build/150926294
[1] https://sourceware.org/pipermail/libc-alpha/2021-August/129718.html
[2] See `${pkgs.glibc.dev}/include/bits/pthread_stack_min-dynamic.h`
[3] https://github.com/boostorg/thread/issues/283
[4] https://github.com/conan-io/conan-center-index/pull/361
- boost 167 removed on staging-next (7915d1e03f) × boost attributes are inherited on staging (d20aa4955d)
- linux kernels were moved to linux-kernels.nix on staging-next (c62f911507) × hardened kernels are versioned on staging (a5341beb78) + removed linux_5_12 (e55554491d)
- conflict in node-packages – I regenerated it using node2nix from nixos-unstable (does not build on staging)
There is an edge case when cross compiling where the auto detection
script would not correctly recognize the compiler (as it is only
good at recognizing native compilers, really, which we don't have
anymore since we don't need the build->build one anymore).
If bootstrap.sh doesn't detect the compiler correctly, it'll generate
a project-config.jam with a syntax error which breaks the build in a
hard to spot way: only a warning is displayed after configuring, the
build will appear to run normally until it fails quietly just before
installing. By providing it explicitly, we can prevent this.
