Package Details: graal-bin 19.0.0-2

Git Clone URL: (read-only)
Package Base: graal-bin
Description: Universal virtual machine for running applications written in a variety of languages (JVM-based, LLVM-based, or other)
Upstream URL:
Licenses: custom
Conflicts: graal
Provides: graal, java-environment=8, java-runtime=8
Submitter: lucaswerkmeister
Maintainer: lucaswerkmeister
Last Packager: lucaswerkmeister
Votes: 16
Popularity: 0.939886
First Submitted: 2018-05-02 22:30
Last Updated: 2019-05-30 10:58

Dependencies (3)

Required by (1000)

Sources (1)

Latest Comments

1 2 Next › Last »

sogaiu commented on 2019-05-30 16:01

@lucaswerkmeister: No worries! Thanks for the update and your work on this matter, very much appreciated.

I tried the graal-native-image-bin package and noticed that the last step gives us a symlink named after pkgname_, which in this case ends up being "graal-native-image". Would it be possible to have this be named "native-image" instead (or additionally)?

May be I should have posted this as a comment for graal-native-image-bin. Hope that was ok.

lucaswerkmeister commented on 2019-05-30 11:01

sogaiu: Sorry for the delay – yes, most of this has been done already :/ I just created the graal-native-image-bin package, and it’s almost a complete copy+paste of the graalpython-bin PKGBUILD, all the Graal packages use the same META-INF format. The only reason this has been delayed for so long is that I’ve been very busy and didn’t know how long this update would take. It turns out it didn’t take long at all (less than 30 minutes, I believe), I probably could’ve squeezed that in a few days earlier. Sorry :(

sogaiu commented on 2019-05-30 07:13

May be this has been done already, but FWIW, I took a look at the mentioned extra native-image jars. One of them is at:

Unzipping the .jar file yields 2 directories: META-INF and jre.

It appears that jre is a directory tree of files necessary for native-image operation.

META-INF appears to contain at least information about the permissions for the native-image-related files that live under jre, but also information about symlinks (to be created?) for those files. These files are named "permissions" and "symlinks", respectively.

The formats seem straight-forward enough. For permissions, it appears each line represents one file path, a typical one being:

bin/native-image = rwxrwxrwx

For symlinks, it's also one line per symlink, e.g.:

bin/native-image = ../jre/bin/native-image

where what's on the left of = is a symlink to be created, and what's on the right of = is where it should point.

For both permissions and symlinks, the paths on the left of the = all appear to be relative to where graal would get installed (i.e. /usr/lib/jvm/java-8-graal)

Didn't succeed in turning up whether there are existing tools to process these files, apart from gu.

Brief examination of the output for gu --help / gu install -h didn't suggest that the tool could be told where the results should go. However, I noticed the existence of the GRAALVM_HOME environment variable elsewhere. Perhaps setting this to an appropriate value in the PKGBUILD and then invoking "gu install native-image" will yield the native-image files in an appropriate location for package building purposes.

Any thoughts?

sogaiu commented on 2019-05-28 01:46

@lucaswerkmeister: Did you decide on an approach?

I'd very much like to use the native-image for Graal 19 as there was a breaking change introduced ( that doesn't work with the native-image from Graal 1.0.0 rc16's native-image, and it happens that something I'm working on needs this.

Not sure how much help I could be, but I'm at least motivated to participate, so please let me know if there is anything that needs doing.

sogaiu commented on 2019-05-14 21:22

I tried to locate some information on where the upstream folks are going with this gu thing and their rationale for splitting out native-image, but I haven't found anything relevant so far.

No strong opinion, but FWIW, if it's easier, perhaps starting with including native-image and if necessary create a separate package later? Don't know how many folks are using native-image already, but it seems less surprising to not change so suddenly and without warning. May be the upstream folks hinted at this somewhere before this release?

lucaswerkmeister commented on 2019-05-14 18:12

Ah, so that’s why there are extra native-image JARs in the release – I should’ve paid attention to those :)

I guess I can either update this package to include native-image, or have it in a separate package (like upstream), presumably recommended by this package. Any thoughts on what’s better?

sogaiu commented on 2019-05-14 15:53

From graal 19, native-image doesn't appear to be bundled any more:

Any thoughts on this?

jdc commented on 2019-05-12 03:22

Thanks for the speedy update! :)

lucaswerkmeister commented on 2018-12-07 22:50

graaljs RC10 requires function expressions to be parenthesized 1, so the test script now becomes:

#!/usr/lib/jvm/java-8-graal/jre/languages/R/bin/Rscript --polyglot
jsPlus = eval.polyglot('js', '(function(s1, s2) { return s1 + s2; })')
pythonPlus = eval.polyglot('python', 'lambda s1, s2: s1 + s2')
rubyOne = eval.polyglot('ruby', '1')
pythonOne = eval.polyglot('python', '1')
rOne = 1
print(pythonPlus(jsPlus(rubyOne, pythonOne), rOne))

lucaswerkmeister commented on 2018-10-22 10:32

By the way, if anyone wants to take over this package in the future – here’s the script I use to test new package versions after building and locally installing them, before pushing them to AUR:

#!/usr/lib/jvm/java-8-graal/jre/languages/R/bin/Rscript --polyglot
jsPlus = eval.polyglot('js', 'function(s1, s2) { return s1 + s2; }')
pythonPlus = eval.polyglot('python', 'lambda s1, s2: s1 + s2')
rubyOne = eval.polyglot('ruby', '1')
pythonOne = eval.polyglot('python', '1')
rOne = 1
print(pythonPlus(jsPlus(rubyOne, pythonOne), rOne))

If all the packages still work, this should print:

[1] 3