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.
