This allows packages that require several dotnet versions to build (like
BeatSaberModManager) to properly depend on the dotnet-sdk specific deps.
This in turns avoids having to regenerate the deps of those packages
after each dotnet-sdk update.
This also changes nuget-to-nix to accept a file with a list of
exclusions instead of a folder.
Our gcc-arm-embedded expressions download binaries instead of
building from source. Let's add the appropriate `sourceProvenance`
for this kind of thing.
* dart: 2.18.4 -> 2.19.3
https://dart.dev/guides/whats-new#january-25-2023-219--30-alpha-releases
* dart: move interpreters -> compilers
Dart is not an interpreted language by default. It can JIT compile, but
ultimately runs on a VM.
Languages which are similar in this regard, like Java and Go also
are sorted into interpreters.
* dart: add primitive tests
* dart: remove version override in sources
* dart: make codesign available in tests
* dart: format
---------
Co-authored-by: Weijia Wang <9713184+wegank@users.noreply.github.com>
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
If RUSTFLAGS is set in the environment, Cargo will ignore rustflags
settings in its TOML configuration. So setting RUSTFLAGS=-g (like
separateDebugInfo does) to generate debug info breaks
dynamically-linked Rust packages on musl. This breakage is visible
for any packages that call into C dynamic libraries. If the binary is
linked directly to a C dynamic library, it will fail to build, and if
it depends on a Rust library which links a C dynamic library, it will
segfault at runtime when it tries to call a function from the C
library. I noticed this because pkgsMusl.crosvm is broken for this
reason, since it sets separateDebugInfo = true.
It shouldn't be possible to end up with broken binaries just by using
RUSTFLAGS to do something innocuous like enable debug info, so I think
that, even though we liked the approach of modiyfing .cargo/config
better at the time, it's become clear that it's too brittle, and we
should bite the bullet and patch the compiler instead when targetting
musl. It does not appear to be necessary to modify the compiler at
all when cross-compiling /from/ dynamically-linked Musl to another
target, so I'm only checking whether the target system is
dynamically-linked Musl when deciding whether to make the modification
to the compiler.
This reverts commit c2eaaae50d
("cargoSetupHook: pass host config flags"), and implements the
compiler patching approach instead.
Relevant upstream issue: ziglang/zig#14559
The patch is a backport of fixes that landed in zig-master and can
be removed with zig-0.11 release.
Additionally, make sure we link statically against LLVM to avoid
unpleasant runtime surprises originating from mixing static and
dynamic LLVM libraries.
Finally, unbreak Zig 0.10.1 on macOS.
We previously thought that we only need python if we were going to run
./boot or using emscripten which implements all its wrappers in
python (and likes to reinvoke them). As it turns out, though, hadrian
likes to invoke python itself for generating certain headers of rts
using a script shipped with the GHC source. This fact was obscured
before, since (presumably) sphinx would propagate python into PATH.
The previous approach of manually repeating a complex pattern inside Common Lisp
implementation package declarations was fragile and hard to change. After
reading python and lua modules code in Nixpkgs, I was able to come up with
something better.
The function `wrapLisp` doesn't need to be inside package declarations so all
the code for wrapping Lisps can be in `all-packages.nix`.
This works by wrapping the `override` function created from `mkDerivation` to
accept a new argument `packageOverrides`.
One problem with this is that `override.__functionArgs` disappears. But one can
look at the source code of a package to discover what can be overridden.
Due to link time dead code elimination not working on aarch64-darwin,
some unused store path references in Paths_* modules are retained. This
causes reference cycles when a separate `bin` output is used.
To prevent this, add a patch to Cabal as shipped by GHC which infers
based on the installation layout (which is influenced by
enableSeparateBinOutput, enableSeparateDataOutput etc. in a Nix build)
which references can be retained without causing a reference cycle. This
ensures that packages that were fine with a bin output will also work on
aarch64-darwin. Packages that cause a reference cycle anyways (by
actually using references that do cause one) fail due to a missing
symbol – here we are trading the overall benefit for a more confusing
error message.
For details, refer to the explanation comment in the patch.
Port of 6d0c87602f ("llvmPackages_15.llvm: add in a missing check
dep").
I did not include the sysctl nativeCheckInputs change from that
commit, as it looks like it was included by mistake and was supposed
to be in c7231c0b6d ("llvmPackages_15.llvm: run the tests on macOS").
I've also included the doCheck default from that commit (without the
change to run on non-Linux), as 6d0c87602f just set it to true.
Port of 404ef6b6c9 ("llvmPackages_15.clang: drop the C++ std version
`-DCMAKE_CXX_FLAG`"). The commit mentioned as removing the need for
the override[1] first appeared in LLVM 10.
[1]: 2724d9e129
Port of 2a58596dd2 ("llvmPackages_15.llvm: enable polly by default").
It should be ported all the back to LLVM 12, but I haven't done that
here because going further back than 14 requires fixing patches, and
I'm focused on my goal of getting the delta between LLVM 15 and LLVM
git under control — it's going to be hard enough to accomplish that.
compiler-rt has accumulated several regressions that prevent it from building
on ARMv6. It is important to note that there are two major versions of ARMv6:
base ARMv6 and ARMv6K. ARMv6K includes several important new instructions,
such as non-word size atomic operations (ldrexd, strexd, etc.) and the yield
instruction. Most ARMv6 CPUs actually implement ARMv6K, including all those used
in Raspberry Pis, but nixpkgs' "raspberryPi" platform targets base ARMv6.
compiler-rt versions 8-14 fail to build on ARMv6 and ARMv6K. compiler-rt 15 (not
yet in nixpkgs) builds on ARMv6K but not ARMv6. This patch fixes versions 9-14
on both ARMv6 variants. The patches don't apply cleanly to version 8, and I
figured it wasn't worth carrying another version of the patches for such an old
version.
A total of five patches are required to get compiler-rt building on ARMv6:
* armv6-mcr-dmb.patch: use `mcr` to provide the equivalent of `dmb` on ARMv6.
Included in LLVM 15.
* armv6-sync-ops-no-thumb.patch: prevent certain atomic operation functions
from using Thumb mode. Included in LLVM 15.
* armv6-no-ldrexd-strexd.patch: don't use ldrexd or strexd, which are not
available in base ARMv6. Submitted upstream by me.
* armv6-scudo-no-yield.patch: use nop instead of yield on ARMv6 in standalone
scudo. Required by versions >=13, since they enable standalone scudo.
Submitted upstream by me.
* armv6-scudo-libatomic.patch: link standlone scudo to libatomic on ARMv6 (and
any other platforms that need it). Not yet submitted because the backport is
a bit different from the upstream version and I need to test it.
`*.*.rts.*.opts` is actually copied from the migration GHC blog post,
but does not, actually, parse: The format is
`<stage>.<package>.<program>.<filetype>.<setting>`, so it would need to
be `*.rts.ghc.opts`. This is already achieved by the broader rule on the
next line.
- Christmas is over!
- Upstream has changed the name of the target triplet used for the JS
backend from js-unknown-ghcjs to javascript-unknown-ghcjs, since Cabal
calls the architecture "javascript":
6636b67023
Since the triplet is made up anyways, i.e. autoconf does not support
it and Rust uses different triplets for its emscripten backends, we'll
just change it as well.
- Upstream fixed the problem with ar(1) being invoked incorrectly by stage0:
e987e345c8
Hadrian does this automatically unfortunately, but unless we correctly
set enableShared as well, mkDerivation will try building shared libs
which will inevitably fail due to missing shared core packages.
Let's stay away from fully_static which does a lot of funky stuff and
was not working before anyways for pkgsStatic.
Without the change `openjdk` build fails on `staging-next` as:
> installing
> mv: missing destination file operand after '/nix/store/pwgvafi1xwa6l0dygmcyr1sl27dhpy67-openjdk-19.0.2+7/lib/openjdk'
> Try 'mv --help' for more information.
Without the change `openjdk` build fails on `staging-next` as:
> installing
> mv: missing destination file operand after '/nix/store/pwgvafi1xwa6l0dygmcyr1sl27dhpy67-openjdk-19.0.2+7/lib/openjdk'
> Try 'mv --help' for more information.
Without the change `openjdk` build fails on `staging-next` as:
> installing
> mv: missing destination file operand after '/nix/store/pwgvafi1xwa6l0dygmcyr1sl27dhpy67-openjdk-19.0.2+7/lib/openjdk'
> Try 'mv --help' for more information.
This is needed for faster builds when debugging the opencv derivation,
and it's more consistent with other cuda-enabled packages
-DCUDA_GENERATION seems to expect architecture names, so we refactor
cudaFlags to facilitate easier extraction of the configured archnames
This is a hot-fix to un-break cuda-enabled packages (like tensorflow,
jaxlib, faiss, opencv, ...) after the gcc11->gcc12 bump. We should
probably build the whole downstream packages with a compatible stdenv
(such as gcc11Stdenv for cudaPackages_11), but just pointing nvcc at the
right compiler seems to do the trick
We already used this hack for non-redist cudatoolkit. Now we use it more
consistently.
This commit also re-links cuda packages against libstdc++ from the same
"compatible" gcc, rather than the current stdenv. We didn't test if this
is necessary -> need to revise in further PRs.
NOTE: long-term we should make it possible to override -ccbin and use
e.g. clang
This was added in 00839fea22 ("llvmPackages_15.compiler-rt: fixes for Darwin"),
which says:
> this introduces a codesigning related patch that we can drop once
> #195107 goes through
The referenced PR ("sigtool: 0.1.2 → 0.1.3") has now been merged, so
I'm dropping the patch as instructed.
The effect of `.out // { outputSpecified = false; }` in these cases
is to select the default output explicitly, but then make the
selection implicit until `overrideAttrs` is called. Previously
`overrideAttrs` would not preserve output selection, masking the
apparently unnecessary behavior of this workaround.
For `libllvm-polly`, this logic does not apply, as it does not
select the default output.
The `outputSpecified` workaround was introduced in
https://github.com/NixOS/nixpkgs/pull/122554
and was perhaps rushed because of a release deadline, and expected
delays from mass rebuilds.
The change in `overrideAttrs` behavior was added in
5b2f597b11 / https://github.com/NixOS/nixpkgs/pull/211685
and the problem was discovered in https://github.com/NixOS/nixpkgs/pull/218537,
which may contain further information.
Port of 44165d3657 ("llvmPackages_{14, git}.clang: add nostdlibinc flag")
to Clang 15. It was originally thought this wasn't needed[1], but it is,
to fix expressions like the following:
with import ./. {};
llvmPackages_15.libcxxStdenv.mkDerivation {
name = "libcxx-stdenv-c++-test";
dontUnpack = true;
input = ''
#include <cstdlib>
int main() {
std::abort();
return 0;
}
'';
passAsFile = [ "input" ];
installPhase = ''
$CXX -c -o $out -x c++ $inputPath
'';
}
[1]: https://github.com/NixOS/nixpkgs/pull/194634#issue-1398202534
We previously disabled this based on a now-closed issue from 2015 [0].
I think enough time has passed that we can give it a shot again, given
that the in the worst case scenario we revert, and in the best case
scenario we get a performance boost.
[0]: https://github.com/rust-lang/rust/issues/30181
