There is a code generation bug in Cabal-3.6.3.0. For packages configured with
--enable-relocatable, Cabal would generate code that doesn't compile.
There isn't an upstream issue, but the issue is described in the commit that
fixed it:
6c796218c9
It was fixed in Cabal-3.8.*
Backport the fix to the Cabal library that ships with ghc-9.4.4
Cabal 3.8 ships with ghc-9.6, so when 9.6 is released this fix shouldn't be
necessary.
This reverts commit 386aba3115.
As I understand it from reading
<https://llvm.org/docs/DeveloperPolicy.html#copyright-license-and-patents>,
the structure of LLVM licensing is as follows:
- They're in the process of relicensing to Apache-2.0 WITH LLVM-exception,
but they haven't got permission to relicense all the code yet.
This means that some of the code can be used under the new license,
but not all of it, and it's difficult to know which is which. This
license is therefore probably not useful yet, until the relicensing
effort is commit.
- While the relicensing effort is ongoing, code being contributed to
LLVM has to have permission to be used under the old and new
licensing schemes. Since the new licensing scheme can't be used
for all code yet, it only makes sense to use LLVM's code under the
old licensing scheme at the moment.
- The old licensing scheme is that code for the LLVM components we
care about is all available under the NCSA license, and some
components are optionally available under a different license,
usually the MIT license, instead.
So I think we should go back to just listing NCSA, or NCSA/MIT, and
forget about the new license until it actually becomes useful,
i.e. LLVM's relicensing effort is complete.
LLVM-exception only makes sense when used with the Apache 2.0 license,
so let's combine them, so it's not possible to forget one of them like
happened with llvm_15.
with structuredAttrs lists will be bash arrays which cannot be exported
which will be a issue with some patches and some wrappers like cc-wrapper
this makes it clearer that NIX_CFLAGS_COMPILE must be a string as lists
in env cause a eval failure
As cudatoolkit is currently written, 11.8 introduces a broken symlink in `include` (also named `include`) and in `lib` (named `lib64`).
This trips up some consumers, like `tensorflow-gpu`.
As of Rust 1.67.0, the cargo-clippy binary now relies on the rustc_private
libraries [0], so let's do the RPATH fixup to it too.
I've also added a comment to explain the RPATH situation, as it took me
a bit to figure out.
[0]: https://github.com/rust-lang/rust-clippy/pull/9541
ripgrep is a very popular grep replacement (similar to fd and find)
and wezterm is a popular terminal emulator which has a big codebase with
lots of features tested (it also broke in the past multiple times on
rustc upgrades.).
26b9a2f4a1 changes Zig 0.10 to build the
compiler (notably *not* its outputs, at least not by default) with
its baseline CPU target, but we should ideally do it for both versions
to increase reproducibility, as well as increase the number of users who
are able to use Hydra-provided Zig binaries.
This also adds a comment above the flag in 0.10, to explain why we're adding
the flag, as we do with the RPATH one.
See https://github.com/NixOS/nixpkgs/issues/214356 and https://github.com/NixOS/nixpkgs/issues/185665
for further context.
