Reverts #162607 / 1748887ff2.
Reason for revert: This change caused llvm-config{,-native} to be unable
to find static archives bundled with LLVM, as has been [reported]. Ever
since #152944 using moveToOutput in LLVM is _evil_ because llvm-config
obtains it knowledge about the installation locations from the CMake
configure step.
Consequently a change like #162607 will need to be implemented by making
LLVM itself install the static archives to the correct location or by
adding yet another patch which updates llvm-config's knowledge of the
location. The latter is not desireable in my opinion, though, since it
is just asking for this sort of trouble: Before #152944 we had an
outputs.patch that did this sort of things which broke spectacularly in
edge cases.
Fixes#148117.
[reported]: https://github.com/NixOS/nixpkgs/issues/148117#issuecomment-1158245576
Since the setting DCMAKE_SKIP_BUILD_RPATH was disabled, we can now run
the checkPhase of cmake derivations without having to tweak the
LD_LIBRARY_PATH anymore.
Without the change build fails on darwin as:
duplicate symbol '_static_code_space_free_pointer' in:
alloc.o
traceroot.o
duplicate symbol '_static_code_space_free_pointer' in:
alloc.o
gencgc.o
Without the change -fno-common toolchain like llvm-11 fails as:
ld: libcamlrun.a(minor_gc.o):/build/ocaml/byterun/caml/major_gc.h:67: multiple definition of
`caml_major_ring'; libcamlrun.a(stacks.o):/build/ocaml/byterun/caml/major_gc.h:67: first defined here
Since the musl / alpine bindist now uses the GMP backend, we need to
learn to tell Hadrian bindists about GMP. Hadrian bindists no longer
have the buildinfo files, instead we need to patch the package db before
installing and recache it afterwards which is not too hard, luckily.
Same goes for libiconv and base as well as libffi and rts on
darwin (those bindists are all produced using hadrian).
See also: https://gitlab.haskell.org/ghc/ghc/-/issues/21554#note_431000
Note that pkgsMusl.haskell.compiler.ghc922Binary still has severe
issues: It can't produce shared libraries because the bindist ships
none (and using the GMP backend has a hard requirement for shared
objects, apparently) and ghci segfaults for unknown reasons at the
moment. However, I've successfully compiled hadrian with it so far, so
perhaps it's good enough.
If HARECACHE is unset, it hare will default to attempting to cache files
relative to $HOME, which isn't writable during a build. Set HARECACHE to
a suitable location so packages that are built with hare don't have to
manually handle this.
A few complex math tests have been failing since they were added, so
disable the failing cases for now.
> 3 tests failed:
> math::complex::cos: Assertion failed: ./math/complex/+test.ha:1088:2
> math::complex::cosh: Assertion failed: ./math/complex/+test.ha:1114:2
> math::complex::exp: Assertion failed: ./math/complex/+test.ha:1140:2
>
> 372 passed; 3 failed; 375 tests completed in 1.19521s
This was disabled basically by accident before.
The links are jacked, but that was is true for every package; it is not
unique to this PR. I fixed it upstream here:
https://github.com/haskell/haddock/pull/1482
but it's not in any release distributions yet I don't think.
Fixes#171841
The previous releases of zlib were not sensitive to incorrect CRC
inputs with bits set above the low 32. Some programs were depended on
this behavior, including GraalVM. So this commit backports a patch from
`zlib` develop that brings back the old behavior. This will probably
be included in the next release of zlib.
Before:
```
$ rm -rf ~/.babashka
$ bb -e "(babashka.pods/load-pod 'clj-kondo/clj-kondo \"2022.05.31\")"
Downloading pod clj-kondo/clj-kondo (2022.05.31)
----- Error --------------------------------------------------------------------
Type: java.util.zip.ZipException
Message: invalid entry CRC (expected 0x269cdf2c but got 0x13b86fd8)
Location: <expr>:1:1
----- Context ------------------------------------------------------------------
1: (babashka.pods/load-pod 'clj-kondo/clj-kondo "2022.05.31")
^--- invalid entry CRC (expected 0x269cdf2c but got 0x13b86fd8)
----- Stack trace --------------------------------------------------------------
babashka.pods.impl.resolver/unzip - <built-in>
babashka.pods.impl.resolver/resolve/fn--30674 - <built-in>
clojure.core/mapv/fn--8535 - <built-in>
clojure.core.protocols/fn--8244 - <built-in>
clojure.core.protocols/fn--8204/G--8199--8213 - <built-in>
... (run with --debug to see elided elements)
babashka.pods.sci/load-pod/fn--30887 - <built-in>
babashka.pods.sci/load-pod - <built-in>
clojure.core/apply - <built-in>
babashka.impl.pods/load-pod - <built-in>
user - <expr>:1:1
```
After:
```
$ rm -rf ~/.babashka
$ ./result/bin/bb -e "(babashka.pods/load-pod 'clj-kondo/clj-kondo \"2022.05.31\")"
Downloading pod clj-kondo/clj-kondo (2022.05.31)
Successfully installed pod clj-kondo/clj-kondo (2022.05.31)
```
The issue should affect other programs using GraalVM, but this was the
test that I had at hand.
otherwise in situations where we don't have a working sandbox
(darwin), if /usr/share/emacs happens to exist, the install
phase will try to put its lisp files there and fail due to
permissions.
Workaround build failure on -fno-common toolchains like upstream
gcc-10. Otherwise build fails as:
ld: vm/vm.a(cogit.o):spur64src/vm/cogitX64SysV.c:2552: multiple definition of
`traceStores'; vm/vm.a(gcc3x-cointerp.o):spur64src/vm/cogit.h:140: first defined here
Workaround build failure on -fno-common toolchains like upstream
gcc-10. Otherwise build fails as:
ld: ./libgclp.a(user_match.o):(.bss+0x18): multiple definition of
`tf'; ./libpre_gcl.a(main.o):(.bss+0x326d90): first defined here
Workaround build failure on -fno-common toolchains like upstream
gcc-10. Otherwise build fails as:
ld: cexp.o:(.bss+0x40): multiple definition of `obstck'; cccp.o:(.bss+0x0): first defined here
Workaround build failure on -fno-common toolchains like upstream
gcc-10. Otherwise build fails as:
ld: gsttypefindelement.o:(.bss._gst_disable_registry_cache+0x0): multiple definition of
`_gst_disable_registry_cache'; gst.o:(.bss._gst_disable_registry_cache+0x0): first defined here
openjfx17 is not affected.
`node-packages.nix` was regenerated after having run `generate-node-packages.sh`
in order to pick up dependencies for `elm-pages`. In addition, we add `elm`,
`elm-review`, and `elm-optimize-level-2` to the `PATH` for `elm-pages` since those
are needed at runtime.
A patch is also included to fix an issue where files are copied from the `nix-store`
as read-only (credit to @bcardiff for that fix). An upstream issue
https://github.com/dillonkearns/elm-pages/issues/305 has been opened to track this.
Otherwise attempt to build ghcHEAD from local checkout fails as:
$ nix build -L --impure --expr 'with import ~/nm {}; haskell.compiler.ghcHEAD.overrideAttrs (oa: { src = ./.; patches = []; nativeBuildInputs = oa.nativeBuildInputs ++ [ git ]; })' --keep-failed
...
ghc> checking C++ standard library flavour... ./configure: line 11487: /nix/store/r7r10qvsqlnvbzjkjinvscjlahqbxifl-gcc-wrapper-11.3.0/bin/cxx: No such file or directory
I think 'cxx' is not provided by stdenv.
The configure script has changed and no longer seems to provide a way
to specify the location of the x11 libraries or headers. Therefore
these configure options have been dropped.
Very confusingly, the `isPowerPC` predicate in
`lib/systems/inspect.nix` does *not* match `powerpc64le`!
This is because `isPowerPC` is defined as
isPowerPC = { cpu = cpuTypes.powerpc; };
Where `cpuTypes.powerpc` is:
{ bits = 32; significantByte = bigEndian; family = "power"; };
This means that the `isPowerPC` predicate actually only matches the
subset of machines marketed under this name which happen to be 32-bit
and running in big-endian mode which is equivalent to:
with stdenv.hostPlatform; isPower && isBigEndian && is32bit
This seems like a sharp edge that people could easily cut themselves
on. In fact, that has already happened: in
`linux/kernel/common-config.nix` there is a test which will always
fail:
(stdenv.hostPlatform.isPowerPC && stdenv.hostPlatform.is64bit)
A more subtle case of the strict isPowerPC being used instead of the
moreg general isPower accidentally are the GHC expressions:
Update pkgs/development/compilers/ghc/8.10.7.nix
Update pkgs/development/compilers/ghc/8.8.4.nix
Update pkgs/development/compilers/ghc/9.2.2.nix
Update pkgs/development/compilers/ghc/9.0.2.nix
Update pkgs/development/compilers/ghc/head.nix
Since the remaining legitimate use sites of isPowerPC are so few, remove
the isPowerPC predicate completely. The alternative expression above is
noted in the release notes as an alternative.
Co-authored-by: sternenseemann <sternenseemann@systemli.org>
* origin/staging-next: (62 commits)
Re-Revert "lua: fix on darwin by using makeBinaryWrapper (#172749)"
openldap: fix cross-compilation
makeBinaryWrapper: fix codesign on aarch64-darwin
python3Packages.ldap: fix linking with openldap 2.5+
Revert "lua: fix on darwin by using makeBinaryWrapper (#172749)"
wine: enable parallel build again
pkgsi686Linux.gdb: fix formatting for 32-bit systems
gtk4: Fix incorrect merge
nixos/openldap: use upstream unit defaults
openldap: update maintainers
openldap: 2.4.58 -> 2.6.2
Revert "Add mingwW64-llvm cross-system."
lua: fix on darwin by using makeBinaryWrapper (#172749)
python310Packages.python-mimeparse: execute tests
pandas: fix darwin build
gtk3: 3.24.33 -> 3.24.33-2022-03-11
gtk4: patch fixing g-c-c crashes
e2fsprogs: patch for CVE-2022-1304
firefox-unwrapped: fix cross compilation
rustc: expose correct llvmPackages for cross compile
...
