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
