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
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.
If we build two things in one derivation, it becomes more complicated
and its build time is extended. Therefore we should avoid this if
possible. There's a good opportunity for this with boost: We have
boost-build packaged already. This has the additional benefit that
we can get rid of $CC_FOR_BUILD entirely in boost, meaning we don't
need to rely on (as many) hacks to make boost understand our way of
cross compiling.
Unfortunately boost-build is not backwards compatible, so we need to
build a specific boost-build for each boost derivation (the number
could probably be reduced, but I'm not interested in testing a lot
of boost builds at the moment).
Additionally we fix a few cross compilation problems:
- boost couldn't cope with different types of compilers for native
and cross (as happens if useLLVM is true). Since we only use one
of them per derivation, this is no longer an issue.
- boost didn't find the cross ar and ranlib for compilation (since
it doesn't check $AR or $RANLIB). Instead it used plain ar and
ranlib form $PATH which were the native ones before. This is now
fixed by setting these tools explicitly in user-config.jam (and
no longer providing the native tools).
With these changes, pkgsLLVM.boost builds.
On darwin, instead of patching the clang-darwin.jam definition, we
instead supply -rpath $out/lib via <linkflags> which causes the
correct directory to be added to the libraries' rpaths, so that
they find each other.
Use the attribute mpi to provide a system wide default MPI
implementation. The default is openmpi (as before).
This now allows for overriding the MPI implentation by using
the overlay mechanism. Build all packages with mpich instead
of the default openmpi can now be achived like this:
self: super:
{
mpi = super.mpich;
}
All derivations that have been using "mpi ? null" to provide optional
building with MPI have been change in the following way to allow for
optional builds with MPI:
{ ...
, mpi
, useMpi ? false
}
We can use use `stdenv.hostPlatform.isStatic` instead, and move the
logic per package. The least opionated benefit of this is that it makes
it much easier to replace packages with modified ones, as there is no
longer any issue of overlay order.
CC @FRidh@matthewbauer
This reverts commit c778945806.
I believe this is exactly what brings the staging branch into
the right shape after the last merge from master (through staging-next);
otherwise part of staging changes would be lost
(due to being already reachable from master but reverted).
Boost generates its installed cmake configuration using custom logic
in its own build system; while this logic *knows* where it should be
installed, the generated config overrides the correct information with
new paths based on the location of the cmake configuration file in an
attempt to let the package be relocated after installation.
This patch simply undoes that.
Users who want to patch boost may put a postInstall hook in an overlay, which
requires that that expression runs them on the buildPhase and installPhase.
Andrew Childs