Age | Commit message (Collapse) | Author |
|
|
|
github account deleted
|
|
|
|
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.
|
|
|
|
|
|
- Simplify `preFixup` phase
- Update documentation
- Quote some variables
|
|
|
|
In #168816, we removed support for Python/Ruby/WASM to reduce the
support burden of GraalVM languages that, arguably, are not really being
used.
However, the way that `pkgs.graalvmCEPackages.mkGraal` function works
right now doesn't allow passing a custom sources file, that would allow
someone to compile GraalVM with the additional products (e.g.: Python).
This PR adds this possibility.
So if someone wants to create a custom graalvm11-ce derivation with
Python support, for example, they can do something like this:
```nix
let
graalvm11-ce-custom = pkgs.graalvmCEPackages.mkGraal {
config = {
x86_64-linux = {
products = [ "graalvm-ce" "python-installable-svm" ];
arch = "linux-amd64";
};
};
defaultVersion = "22.0.0.2";
javaVersion = "11";
platforms = "x86_64-linux";
sourcesPath = /home/someone/graalvm11-ce-sources.json;
};
in
{
environment.systemPackages = [ graalvm11-ce-custom ];
}
```
|
|
Co-authored-by: tricktron <tgagnaux@gmail.com>
|
|
|
|
However without support for Native Image, since it is failing to build.
|
|
Those additional languages does not seem to really have much usage
(e.g.: none in nixpkgs). For example, Ruby is pretty much broken for all
environments for quite sometime already, however nobody seemed to border
enough to fix it. They also add a good amount of size to the derivation.
So let's remove them. It should be really easy if someone still cares
for them and want to add them back on their own system: just use the
`mkGraal` function (that we export) to generate their own version of
GraalVM with all extra features they want.
|
|
This package was last updated in 2020. It is out-of-date compared to
upstream and we have the graalvmXX-ce already, that is much better
maintained nowadays.
|
|
|
|
|
|
Co-authored-by: Thiago Kenji Okada <thiagokokada@gmail.com>
|
|
|
|
aarch64-darwin
|
|
The update script fetches the latest versions and only
computes/downloads the sha256 if there is a new version to improve runtime.
|
|
|
|
|
|
graalvm17-ce: 21.3.0 -> 22.0.0.2
|
|
- Remove some unnecessary macOS dependencies (e.g.: GTK3 support)
- Patch openssl.so's Ruby libraries so autoPatchelfIgnoreMissingDeps is
not needed anymore on Linux
- Add support for musl
- Add binutils/stdenv.cc to runtime, making this derivation pure
(it used to depend on GCC installed in system)
- Format file with nixpkgs-fmt
|
|
|
|
|
|
|
|
|
|
Seems that native-image works fine nowadays without it.
|
|
|
|
|
|
- Drop graalvm8 since it was removed by upstream
- Add update.sh script to make it easier to generate hashes for all
platforms
- Fix GraalPython, broken since #141825 (sorry)
- Small refactorings and fixes
|
|
|
|
Only adding support for graalvm11-ce. While there is a graalvm8 release
for aarch64-linux, it is missing some support (like wasm).
Also, it is not used anywhere on the nixpkgs, while graalvm11 is used by
multiple other packages (babashka, clj-kondo, clojure-lsp, etc.).
|
|
This derivation was not updated since Jan 18, 2020. It doesn't
build on Hydra because it needs too much memory (~30GB). And no other
packages depend on it.
Also, this is a very complex package and really difficult to maintain.
It is a blocker for https://github.com/NixOS/nixpkgs/pull/141794, since
a recent bump of broke it.
`graalvm8-ce` is the replacement. It is much more up-to-date (`graalvm`
is on version 19.2.1, `graalvm8-ce` is on version 21.2.0), it is much
easier on Hydra (it uses the binary from Oracle).
I also deprecated `jvmci8` and `mx`. I am not sure if `graalvm8`
supplies them, but if something is missing we can always add it later to
`graalvm8-ce`.
|
|
|
|
|
|
Add dynamic libraries (for now only glibc) to $lib output, so we can use
them with e.g.:
```
native-image -H:CLibraryPath=${graalvm11-ce.lib}/lib ...
```
Reducing the finaly closure size of a GraalVM package since it will not
pull the whole GraalVM as a direct dependency.
|
|
|
|
|
|
|
|
Fix NativePRNG errors when building softwares like `babashka`.
Also temporarly disable JShell in installCheckPhase.
|
|
|
|
|
|
See https://discourse.nixos.org/t/nix-shell-environment-to-debug-a-build-of-an-r-package/11010/4
|
|
|
|
Fix #114495.
Note that OpenJDK 8 does not have jspawnhelper.
|
|
|
|
|
|
Adds needed libraries with `autoPatchelfHook`. This ensures required
libraries are linked for future.
|