Code Monkey home page Code Monkey logo

container's Introduction

GraalVM Container Images

To support container-based development, we provide container images for:

  • Oracle GraalVM
  • GraalVM Community Edition

Oracle GraalVM Container Images

Oracle GraalVM container images are published in the Oracle Container Registry under the GraalVM Free Terms and Conditions (GFTC) license. Learn more at Oracle Help Center.

GraalVM Community Edition Container Images

GraalVM Community Edition container images are published in this GitHub Container Registry. There are different GraalVM Community Edition container images provided depending on the architecture and the Java version. The container images for the latest GraalVM versions (GraalVM for JDK 17, GraalVM for JDK 20, and GraalVM for JDK 21) have a -community suffix. These are: native-image-community, jdk-community, truffleruby-community, nodejs-community, and graalpy-community. The container images are multi-arch, for AMD64 and AArch64 processor architectures, and Linux version.

These are GraalVM Community Edition container images for the latest versions:

Package Description
jdk-community A size compact GraalVM Community Edition container image with the GraalVM JDK.
graalvm-community A GraalVM Community Edition container image.
native-image-community A size compact, RPM-based1, GraalVM Community Edition container image with the Native Image support.
truffleruby-community A size compact, standalone2, GraalVM Community Edition container image with the Ruby runtime. It uses a standalone build of TruffleRuby.
nodejs-community A size compact, RPM-based1, GraalVM Community Edition container image with the Node.js runtime.
graalpy-community A size compact, standalone2, GraalVM Community Edition container image with the GraalPy runtime. It uses a standalone build of GraalPy.

Below is the list of deprecated images that will only receive a last update for 22.3 before being archived:

Package Description Type
jdk A size compact GraalVM Community Edition container image with the GraalVM JDK pre-installed. RPM-based1
graalvm-ce A GraalVM Community Edition container image with the gu utility to install additional features. GU-based
native-image A size compact GraalVM Community Edition container image with the Native Image support. RPM-based1
truffleruby A size compact GraalVM Community Edition container image with the Ruby runtime. It uses a standalone build of TruffleRuby. Standalone2
nodejs A size compact GraalVM Community Edition container image with the Node.js runtime. RPM-based1
graalpy A size compact GraalVM Community Edition container image with the GraalPy runtime. Standalone2

1: RPM-based GraalVM Community Edition container images are based on GraalVM components RPMs that are available for Oracle Linux 7, Oracle Linux 8, and Oracle Linux 9. Similar to any other available packages, you can install these components using yum on Oracle Linux 7, or microdnf on Oracle Linux 8 and 9 based images.

2: Standalone-based GraalVM Community Edition container images based on standalone builds of specific Truffle languages. These images are created as a drop-in replacement for other implementations, and do not contain a Java runtime.

Tags

There are multiple tags that let you choose the level of stability you need including the Java version, build number, and the Linux version. Image tags use the following naming convention:

$version[-muslib(for native image only)][-$platform][-$buildnumber]

The following tags are listed from the most-specific tag (at the top) to the least-specific tag (at the bottom). The most-specific tag is unique and always points to the same image, while the less-specific tags point to newer image variants over time.

21.0.0-ol9-20230919
21.0.0-ol9
21.0.0
21-ol9
21

To pull GraalVM for a specific JDK version, for example, 21, run from a command line:

$ docker pull ghcr.io/graalvm/graalvm-community:21

To use GraalVM JDK as base image in Dockerfile, use:

FROM ghcr.io/graalvm/graalvm-community:21

Read more about GraalVM Community Edition container images here.

Versioning and Update Policy

To allow users to control their update policy, we provide an update policy based on a tag version. To fix the image and allow no updates, you need to use a full version with a release date:

ghcr.io/graalvm/$IMAGE_NAME[:][$java_version][-$os_version][-$date]

For example, ghcr.io/graalvm/jdk-community:21.0.0-ol9-20230919.

You can also set an image to a specific Java version that allows an update for a subversion to be pulled. For instance, using ghcr.io/graalvm/jdk-community:latest, the image will be updated for 23.1.x releases, but not for 23.0.0. Using ghcr.io/graalvm/native-image-community you will always get the latest update available for Native Image GraalVM Community Edition, the latest OS which is now Oracle Linux 9 and Oracle Linux 9 slim, and the latest Java version.

Note some terms and restrictions that may apply to the open source technology. The container image you select and all of the software that it contains is licensed under one or more open source license that are provided in the container image. Your use of the container is subject to the terms of those licenses.

container's People

Contributors

abdelhaira avatar aboullaite avatar brunoborges avatar djelibeybi avatar eregon avatar ezzarghili avatar ierguiti avatar jbochi avatar mlouriz avatar mzachh avatar olyagpl avatar oubidar-abderrahim avatar

Stargazers

avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar

Watchers

avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar

Forkers

bhuvnesh94 ramkrishs aboullaite krisfoster qi77qi loicdescotte atrianac ruannunes batsura-sa itarhri mafulafunk akovari ws6672 aleksandr-filichkin denrykhlov edwardt utgoer-test-org crazyxiongxiong adrianofsp ogaye-ibm jbochi sshyran ierguiti artart788 edwinvincent6211 huangzhaoyi ukv001 ehsaniara goodstudio picpay nithinnambiar

container's Issues

Do not override ENTRYPOINT for truffleruby image

Due to #11 (comment)

I think this is super confusing, it took me over 5 minutes just to find how to get a shell.

$ docker run --rm -it ghcr.io/graalvm/truffleruby:latest bash     
truffleruby: No such file or directory -- bash (LoadError)

$ docker run --rm -it ghcr.io/graalvm/truffleruby:latest /bin/bash             
truffleruby: /bin/bash:1: Invalid char `\177' ('') in expression (SyntaxError)

$ docker run --rm -it --entrypoint bash ghcr.io/graalvm/truffleruby:latest 
bash-4.4#

cc @ezzarghili
I think let's remove the ENTRYPOINT and just have CMD as ruby or ruby --version.
In fact we should maybe also drop CMD altogether, so then the default is a shell, which is the most useful.

Image `ghcr.io/graalvm/native-image-community:21-muslib` cannot build native image inside docker

System requirements

  • Windows/Linux
  • Docker

Step to reproduce

  1. Run the following command:
git clone https://github.com/rost5000/graalvm-docker-build-bug.git && cd ./graalvm-docker-build-bug && docker build .
  1. You can see the error:
#0 3.513 Failed generating 'application' after 2.0s.
#0 3.513
#0 3.513 The build process encountered an unexpected error:
#0 3.513
#0 3.513 > com.oracle.svm.core.util.VMError$HostedError: Unable to run '/tmp/SVM-2564794841615393060/BuiltinDirectives' to compute offsets in C data structures. Is it possible that your antivirus software interferes and puts the resulting file into quarantine?
#0 3.513
#0 3.513 Please inspect the generated error report at:
#0 3.513 /home/app/ms/svm_err_b_20231103T112642.867_pid49.md
#0 3.515
#0 3.515 If you are unable to resolve this problem, please file an issue with the error report at:
#0 3.515 https://graalvm.org/support
------
Dockerfile:15
--------------------
  14 |
  15 | >>> RUN native-image -cp /home/app/ms/build/libs/graalvm-1.0-SNAPSHOT.jar \
  16 | >>>     -H:Class=org.example.Main \
  17 | >>>     -H:Name=application \
  18 | >>>     --no-fallback
  19 |
--------------------
ERROR: failed to solve: process "/bin/sh -c native-image -cp /home/app/ms/build/libs/graalvm-1.0-SNAPSHOT.jar     -H:Class=org.example.Main     -H:Name=application     --no-fallback" did not complete successfully: exit code: 1
  1. It was worked in ghcr.io/graalvm/native-image:ol7-java17-22.3.2 image
  2. If I prepare my own image with installation graalvm and c libs, everything is works.

graalvm-ce images refer to an inaccessible ociregion

ociregion refers to something that ultimately resolves to https://yum-phx.oracle.com/repo/OracleLinux/OL8/baseos/latest/x86_64/repodata/repomd.xml which presumably isn't accessible to people who are outside Oracle's network.

This means builds that attempt to install other packages fail.

Steps to reproduce

  • Not be attached to oracle infrastructure in anyway??
  • Dockerfile :
FROM ghcr.io/graalvm/graalvm-ce:ol8-java11-22

RUN \
    microdnf -y install nc
  • console output:
#4 [1/2] FROM ghcr.io/graalvm/graalvm-ce:ol8-java11-22
#4 sha256:49fff5cbfd35a52ce0b7972211aa89989dd48697891695d40727248cceeeea2f
#4 CACHED

#5 [2/2] RUN     microdnf -y install nc
#5 sha256:1ee39ad5c35decbd7dc4ea3853660cd608552c8a013eeda9901611cd099cf8d5
#5 0.296 Downloading metadata...
#5 85.25 error: cannot update repo 'ol8_baseos_latest': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried; Last error: Curl error (7): Couldn't connect to server for https://yum-phx.oracle.com/repo/OracleLinux/OL8/baseos/latest/x86_64/repodata/repomd.xml [Failed to connect to yum-phx.oracle.com port 443: Connection refused]
#5 ERROR: executor failed running [/bin/sh -c microdnf -y install nc]: exit code: 1
------
 > [2/2] RUN     microdnf -y install nc:
------
executor failed running [/bin/sh -c microdnf -y install nc]: exit code: 1

Workaround

  • Change the dockerfile
FROM ghcr.io/graalvm/graalvm-ce:ol8-java11-22

RUN \
    echo > /etc/dnf/vars/ociregion && \
    microdnf -y install nc
  • console output
#4 [1/2] FROM ghcr.io/graalvm/graalvm-ce:ol8-java11-22
#4 sha256:49fff5cbfd35a52ce0b7972211aa89989dd48697891695d40727248cceeeea2f
#4 CACHED

#5 [2/2] RUN     echo > /etc/dnf/vars/ociregion &&     microdnf -y install nc
#5 sha256:da6d3f2ee3f52d6c07fb2e26d4a9654a1258c3a5771a77495d59054be5cc4dfa
#5 0.298 Downloading metadata...
#5 10.55 Downloading metadata...
#5 21.02 Package                           Repository            Size
#5 21.02 Installing:
#5 21.02  hwdata-0.314-8.10.el8.noarch     ol8_baseos_latest   1.8 MB
#5 21.02  kmod-libs-25-18.0.1.el8.x86_64   ol8_baseos_latest  70.0 kB
#5 21.02  libibverbs-35.0-1.el8.x86_64     ol8_baseos_latest 343.0 kB
#5 21.02  libnl3-3.5.0-1.el8.x86_64        ol8_baseos_latest 331.1 kB
#5 21.02  libpcap-14:1.9.1-5.el8.x86_64    ol8_baseos_latest 172.7 kB
#5 21.02  nmap-ncat-2:7.70-6.el8.x86_64    ol8_appstream     242.2 kB
#5 21.02  pciutils-3.7.0-1.el8.x86_64      ol8_baseos_latest 107.5 kB
#5 21.02  pciutils-libs-3.7.0-1.el8.x86_64 ol8_baseos_latest  55.4 kB
#5 21.02  rdma-core-35.0-1.el8.x86_64      ol8_baseos_latest  60.8 kB
#5 21.02 Transaction Summary:
#5 21.02  Installing:        9 packages
#5 21.02  Reinstalling:      0 packages
#5 21.02  Upgrading:         0 packages
#5 21.02  Obsoleting:        0 packages
#5 21.02  Removing:          0 packages
#5 21.02  Downgrading:       0 packages
#5 21.02 Downloading packages...
#5 21.62 Running transaction test...
#5 21.75 Installing: libnl3;3.5.0-1.el8;x86_64;ol8_baseos_latest
#5 21.84 Installing: pciutils-libs;3.7.0-1.el8;x86_64;ol8_baseos_latest
#5 21.86 Installing: kmod-libs;25-18.0.1.el8;x86_64;ol8_baseos_latest
#5 21.88 Installing: hwdata;0.314-8.10.el8;noarch;ol8_baseos_latest
#5 22.03 Installing: pciutils;3.7.0-1.el8;x86_64;ol8_baseos_latest
#5 22.05 Installing: rdma-core;35.0-1.el8;x86_64;ol8_baseos_latest
#5 22.07 Installing: libibverbs;35.0-1.el8;x86_64;ol8_baseos_latest
#5 22.12 Installing: libpcap;14:1.9.1-5.el8;x86_64;ol8_baseos_latest
#5 22.15 Installing: nmap-ncat;2:7.70-6.el8;x86_64;ol8_appstream
#5 22.24 Complete.
#5 DONE 22.4s

I'm not an oracle linux expert by any means, so I'm not sure if there's any other ramifications of what I've done.

Native-Image cross-compilation from amd64 to arm64 fails on `gcc -v` check

I want to create native images for both amd64 and arm64, and when I attempt that on my x86 machine (Mac), I start the image ghcr.io/graalvm/native-image:21.3 with --platform=linux/arm64.

Out of the box, this fails during the toolchain-check, as running gcc -v from within the Java process fails.

Adding this resolved the issue for me:

ENV JAVA_TOOL_OPTIONS="-Djdk.lang.Process.launchMechanism=vfork"

Should that be added to the graalvm-ce / native-image Docker images?

Btw, adding gcc variants with different target architectures and the related libs to the Docker image would be awesome - then I could run native-image in my home-architecture while creating native images in the target architecture without having to run the whole thing through qemu (which increases the build time by a factor of 20 for me).

The ruby post-install hook was not run for slim images

As we can see
https://github.com/graalvm/container/blob/952ceb4186763bd79c340b636adf89ca7267d2a5/truffleruby/Dockerfile.ol8-slim
doesn't run it, unlike

container/truffleruby/Dockerfile.ol8

Line 29 in 952ceb4

RUN /opt/truffleruby-$GRAALVM_VERSION-linux-amd64/lib/truffle/post_install_hook.sh

This then cause errors whenever the openssl gem is used, including just loading the gem.

Probably the easiest fix is to build the slim images from the non-slim images, and just don't copy the lib/llvm-toolchain.
Alternatively, installing the necessary packages to run the post-install hook, run it and uninstalling these packages might be another way.

arm64 support for musllib based containers

$Subject.
Regular containers has the support for both containers but for musllib based containers, it seems like only amd64. This is an issue when running on m1 mac.

#0 51.16 [1/7] Initializing...                                                                                    (0.0s @ 0.42GB)
#0 51.17 Error: Missing CAP cache value for: NativeCodeInfo:AArch64LibCHelperDirectives:StructInfo:CPUFeatures
#0 51.17 Error: Use -H:+ReportExceptionStackTraces to print stacktrace of underlying exception

When can we expect this feature?

Publish official graalvm-ce Docker images

I am one of the maintainers of the official clojure Docker images, and I would like to provide variants of those images with graalvm & native-image already baked in as the Clojure community has developed quite a bit of interest in building native-images w/ GraalVM. :)

However, I can't do that unless the graalvm-ce images that I would use in my FROM lines are themselves official images on Docker Hub. Would that be something you all were willing to do?

ol8_graalvm_community.repo returning 404's in graalvm/native-image:latest image

Steps to reproduce:

  1. docker run --rm -ti --entrypoint bash ghcr.io/graalvm/native-image:latest
  2. (inside container) microdnf install git (or any other package)

Observed result:

error: cannot update repo 'ol8_graalvm_community': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried; Last error: Status code: 404 for https://yum.oracle.com/repo/OracleLinux/OL8/graalvm/community/repodata/repomd.xml (IP: 69.192.209.79)

Expected result: microdnf downloads repo metadata and installs git

`GLIBC_2.32` not found in `:17-ol9`

Hi all,
I'm using a multistage build where I execute the native-image command with mostly static flag using ghcr.io/graalvm/native-image-community:17-ol9 container. Then I'll copy the executable generated, to distroless container(with glibc). This approach worked just fine without any issues in ol7 and ol8 but when I tried to use ol9 image. I'm getting the following error.
./hello: /lib/aarch64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by ./hello)

This issue is reproducible in both native-imag and native-image-commiunity containers. This issue is not reproducible and works just fine when we use ol7, ol8.

I thought mostly static flag does not pack libc in the executable?

Steps to reproduce

git clone https://github.com/xlight05/graal_ol9_issue
docker build -t test_svc .
docker run  -p 9090:9090 test_svc

Change the base image from ghcr.io/graalvm/native-image-community:17-ol9 to ghcr.io/graalvm/native-image-community:17-ol8 and it should work normally.

curl http://localhost:9090/helloWorld/sayHello

Publish Java19 container images.

Right now for GraalVM CE/native-image tyeps, java 19 images are missing and this might be really helpful to test and validate native images using virtual threads.

Failed to build image with native-image-community:21

Hi

We used GraalVM container images and that worked with ghcr.io/graalvm/native-image package. However according the documentation we should use native-image-community now. But we failed to build our Docker image after that. Here is beginning of the Dockerfile:

FROM ghcr.io/graalvm/native-image-community:21 as graalvm

RUN microdnf update && microdnf install -y unzip tar make

And here's the output/error:

RUN microdnf update && microdnf install -y unzip tar make
#9 0.199 Downloading metadata...
#9 3.408 Downloading metadata...
#9 9.756 Downloading metadata...
#9 11.00 error: Could not depsolve transaction; 5 problems detected:
#9 11.00  Problem 1: glibc-devel-2.34-60.0.2.el9.i686 has inferior architecture
#9 11.00   - package glibc-static-2.34-60.0.2.el9.x86_64 requires glibc-devel = 2.34-60.0.2.el9, but none of the providers can be installed
#9 11.00   - cannot install both glibc-devel-2.34-60.0.3.el9_2.7.x86_64 and glibc-devel-2.34-60.0.2.el9.x86_64
#9 11.00   - cannot install the best update candidate for package glibc-devel-2.34-60.0.2.el9.x86_64
#9 11.00   - problem with installed package glibc-static-2.34-60.0.2.el9.x86_64
#9 11.00  Problem 2: package glibc-static-2.34-60.0.2.el9.x86_64 requires glibc-devel = 2.34-60.0.2.el9, but none of the providers can be installed
#9 11.00   - package glibc-devel-2.34-60.0.2.el9.x86_64 requires glibc-headers = 2.34-60.0.2.el9, but none of the providers can be installed
#9 11.00   - package glibc-devel-2.34-60.0.2.el9.i686 requires glibc-headers = 2.34-60.0.2.el9, but none of the providers can be installed
#9 11.00   - cannot install both glibc-headers-2.34-60.0.3.el9_2.7.x86_64 and glibc-headers-2.34-60.0.2.el9.x86_64
#9 11.00   - cannot install the best update candidate for package glibc-static-2.34-60.0.2.el9.x86_64
#9 11.00   - cannot install the best update candidate for package glibc-headers-2.34-60.0.2.el9.x86_64
#9 11.00  Problem 3: package glibc-static-2.34-60.0.2.el9.x86_64 requires glibc-devel = 2.34-60.0.2.el9, but none of the providers can be installed
#9 11.00   - package glibc-devel-2.34-60.0.2.el9.i686 requires glibc = 2.34-60.0.2.el9, but none of the providers can be installed
#9 11.00   - package glibc-devel-2.34-60.0.2.el9.x86_64 requires glibc = 2.34-60.0.2.el9, but none of the providers can be installed
#9 11.00   - glibc-2.34-60.0.2.el9.i686 has inferior architecture
#9 11.00   - cannot install both glibc-2.34-60.0.3.el9_2.7.x86_64 and glibc-2.34-60.0.2.el9.x86_64
#9 11.00   - package libxcrypt-static-4.4.18-3.el9.x86_64 requires glibc-static(x86-64) >= 2.27, but none of the providers can be installed
#9 11.00   - cannot install the best update candidate for package glibc-2.34-60.0.2.el9.x86_64
#9 11.00   - problem with installed package libxcrypt-static-4.4.18-3.el9.x86_64

GraalVM CE docker image should support M1

Currently ghcr.io/graalvm/graalvm-ce:ol8-java8-21.1.0 outputs a warning that the underlying architecture is not aarch64. Although native-image works it's very slow on M1. I don't yet know how M1 could officially be supported. For now I will leave this issue for further consideration.

Explicitly required module ALL-MODULE-PATH is not available

When trying to build a native image with graalvm-ce-java17-22.2.0 and the following options:

${GRAALVM_HOME}\bin\native-image \
--no-fallback \
--module-path ${LIB_FOLDER} \
--add-modules ALL-MODULE-PATH \
--module ${MAIN_MODULE} \
-H:ConfigurationFileDirectories=META-INF\native-image \
-H:+ReportUnsupportedElementsAtRuntime \
-H:+ReportExceptionStackTraces

I get the following error:

Fatal error: com.oracle.svm.core.util.VMError$HostedError: Explicitly required module ALL-MODULE-PATH is not available
        at org.graalvm.nativeimage.builder/com.oracle.svm.core.util.VMError.shouldNotReachHere(VMError.java:68)
        at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.ModuleLayerFeature.lambda$afterAnalysis$2(ModuleLayerFeature.java:160)
        at java.base/java.lang.Iterable.forEach(Iterable.java:75)
        at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.ModuleLayerFeature.afterAnalysis(ModuleLayerFeature.java:157)
        at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageGenerator.lambda$runPointsToAnalysis$12(NativeImageGenerator.java:752)
        at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.FeatureHandler.forEachFeature(FeatureHandler.java:78)
        at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageGenerator.runPointsToAnalysis(NativeImageGenerator.java:752)
        at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageGenerator.doRun(NativeImageGenerator.java:564)
        at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageGenerator.run(NativeImageGenerator.java:521)
        at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageGeneratorRunner.buildImage(NativeImageGeneratorRunner.java:407)
        at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageGeneratorRunner.build(NativeImageGeneratorRunner.java:585)
        at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageGeneratorRunner.main(NativeImageGeneratorRunner.java:128)

Is the add-modules option not supported in native-image? Or is the option ALL_MODULE_PATH not supported?
The native-image help shows that the option as well as the value should be working.

libfreetype.so.6: cannot open shared object file: No such file or directory 

java.lang.UnsatisfiedLinkError: /usr/lib64/graalvm/graalvm22-ce-java17/lib/libfontmanager.so: libfreetype.so.6: cannot open shared object file: No such file or directory

What could be the problem? I use docker container version 17, jdk package. Is it possible to fix it manually, already on the working container?

native image muslib images are missing arm64 image varian

I'm wondering if this is a conscious decision, as all native image images using muslib only seem to have an amd64 variant, no arm64 variant though. I did not find any documentation regarding this.
I'm build on arm64 with ghcr.io/graalvm/native-image:muslib-ol9-java17-22.3.0. As the image is not natively available as arm64, my mac just falls back to the amd64 variant and uses this one in my multi-arch build targeting arm64 and amd64. This results in no error while building. When I now try to start my build image, it fails with an exec format error as the binary is amd64. This is rather unfortunate, as I took quite a while to figure that out...

The images don't exist

According to the documentation there should be the following images:

  • ghcr.io/graalvm/jdk:java17-22.2, ghcr.io/graalvm/jdk:java17-22.3
  • ghcr.io/graalvm/graalvm-ce:22.3.0-java17-amd64
  • ghcr.io/graalvm/jdk:java17-22.2.0
    and more.

I'm sure that these don't exist. So far I'm only able to pull

  • ghcr.io/graalvm/jdk:22.3.0 for jdk, native-image, graalvm-ce etc. for 22.3.0 and 22.2.0

Am I doing something wrong or is the documentation inaccurate?

Thanks

Invalid ARM64 Image for graalvm-ce:java11-21.2.0, mixed with X86 binaries

The ARm64 Image for graalvm-ce:java11-21.2.0 seems to be invalid and mixed up with X86 Graalvm Binaries.

Executing "gu" inside the Container gives:
"/lib64/ld-linux-x86-64.so.2: No such file or directory"

"file /bin/bash" returns:
ELF 64-bit LSB shared object, ARM aarch64,

While the File Command on the "gu" and java indicates,
that the X86 Version is installed.

The Java8 version however, seems to be build correctly.

aarch in docker hub

Hello,

I'm playing with graal on AWS t4g instances which are aarch (arm) CPUs. I'm using docker for deployment. After update to version 20.3.0 it didn't work anymore. I've notice that there is no aarch versions anymore on dockerhub. Is there any reason for that? Or any alternative to dockerhub where arm images are available?

image

Command yum not found?

Trying to use this as a base image and add a postgres client - but I can't figure out where the yum command has gone.

Can't see anything in the Docker file that's removing it - but it's just not there in the running image.

Any clues gratefully received.

Update for JDK 20

The container images should be kept in sync with the new GraalVM release schedule.

Multibyte characters are garbled

When I compile a Java code with multibyte characters using javac command, failed compile.

Java Source Code

public class Test {
  public static void main(String[] args) {
   System.out.println("↓");
  }
}

Procedures

docker run -v $(pwd):/work -it -w /work \
  ghcr.io/graalvm/graalvm-ce:22.0.0.2 bash

bash-4.4# javac Test.java
Test.java:3: error: unmappable character (0xE2) for encoding US-ASCII
   System.out.println("???");
                       ^
Test.java:3: error: unmappable character (0x86) for encoding US-ASCII
   System.out.println("???");
                        ^
Test.java:3: error: unmappable character (0x93) for encoding US-ASCII
   System.out.println("???");
                         ^
bash-4.4#

Solution for this behavior

I've fixed to change environment variable value of LANG to C.utf8 from en_US.UTF-8.

docker run -v $(pwd):/work -it -w /work \
  -e LANG=C.utf8 \
  ghcr.io/graalvm/graalvm-ce:22.0.0.2 bash

It's working fine.

bash-4.4# javac Test.java
bash-4.4# java Test
↓
bash-4.4#

Proposal

I will propose to change default LANG value to C.utf8 from en_US.UTF-8.

p.s:

The en_US.UTF-8 not installed on container by default.

bash-4.4# locale -a
C
C.utf8
POSIX
bash-4.4#

Incorrect Java version for native-image:java11

The Java version for the next native-image tags does not correspond with the expected version:

  • java11
  • java11-21
  • java11-21.3
  • java11-21.3.0
  • java11-21.3.0-B1
  • ol7-java11
  • ol7-java11-21
  • ol7-java11-21.3
  • ol7-java11-21.3.0
  • ol7-java11-21.3.0-b1

Java 11 is expected but Java 17 is used:

$ docker run -it --rm ghcr.io/graalvm/native-image:java11
GraalVM 21.3.0 Java 17 CE (Java Version 17.0.1+12-jvmci-21.3-b05)

$ docker run -it --rm ghcr.io/graalvm/native-image:ol7-java11
GraalVM 21.3.0 Java 17 CE (Java Version 17.0.1+12-jvmci-21.3-b05)

Provide a JRE?

Hi 🙂

The images are quite big and if we install the js module with gu, for example, our images a getting huge (>1Gb)
Would it be possible for you to provide a JRE and some Docker images containing this JRE?

Jules

native-image in the provided docker image fails in linker with `--enable-https`

Running native-image on any input, including a trivial hello world class, fails with ld returned 1 exit status if the --enable-https switch is included. The same input succeeds in my local instalation of graalvm.

My script to reproduce the issue:

#! /usr/bin/env bash

cat << EOF > Hello.java
public class Hello {
  public static void main(String[] args) {
    System.out.println("hello!");
  }
}
EOF

javac Hello.java

docker run -v $(pwd):/hello  --rm  --workdir /hello  -ti ghcr.io/graalvm/native-image:22   -cp . Hello  --enable-https

Which fails with the output:

===============================================================================================
GraalVM Native Image: Generating 'hello' (executable)...
===============================================================================================
[1/7] Initializing...                                                           (2.3s @ 0.20GB)
 Version info: 'GraalVM 22.1.0 Java 17 CE'
 C compiler: gcc (redhat, x86_64, 8.5.0)
 Garbage collector: Serial GC
[2/7] Performing analysis...  [[3.525s][warning][jni,resolve] Re-registering of platform native method: java.lang.PanwHooksNs.HookArgs0()V from code in a different classloader
[3.526s][warning][jni,resolve] Re-registering of platform native method: java.lang.PanwHooksNs.HookArgs1(Ljava/lang/Object;)V from code in a different classloader
[3.526s][warning][jni,resolve] Re-registering of platform native method: java.lang.PanwHooksNs.HookArgs2(Ljava/lang/Object;Ljava/lang/Object;)V from code in a different classloader
[3.526s][warning][jni,resolve] Re-registering of platform native method: java.lang.PanwHooksNs.HookArgs3(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)V from code in a different classloader
[3.526s][warning][jni,resolve] Re-registering of platform native method: java.lang.PanwHooksNs.HookArgs4(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)V from code in a different classloader
**************]                                 (18.2s @ 0.79GB)
   5,583 (85.83%) of  6,505 classes reachable
   7,476 (54.98%) of 13,598 fields reachable
  26,282 (55.24%) of 47,579 methods reachable
     350 classes,    96 fields, and 1,012 methods registered for reflection
      61 classes,    67 fields, and    54 methods registered for JNI access
[3/7] Building universe...                                                      (1.5s @ 1.22GB)
[4/7] Parsing methods...      [*]                                               (1.2s @ 1.75GB)
[5/7] Inlining methods...     [****]                                            (1.6s @ 1.48GB)
[6/7] Compiling methods...    [****]                                           (14.3s @ 1.56GB)
[7/7] Creating image...
                                                         (0.0s @ 2.19GB)
Fatal error: java.lang.RuntimeException: There was an error linking the native image: Linker command exited with 1

Linker command executed:
/usr/bin/gcc -z noexecstack -Wl,--gc-sections -Wl,--dynamic-list -Wl,/tmp/SVM-1043361363098864337/exported_symbols.list -Wl,--exclude-libs,ALL -Wl,-x -o /hello/hello hello.o /usr/lib64/graalvm/graalvm22-ce-java17/lib/svm/clibraries/linux-amd64/liblibchelper.a /usr/lib64/graalvm/graalvm22-ce-java17/lib/static/linux-amd64/glibc/libnet.a /usr/lib64/graalvm/graalvm22-ce-java17/lib/static/linux-amd64/glibc/libextnet.a /usr/lib64/graalvm/graalvm22-ce-java17/lib/static/linux-amd64/glibc/libnio.a /usr/lib64/graalvm/graalvm22-ce-java17/lib/static/linux-amd64/glibc/libjava.a /usr/lib64/graalvm/graalvm22-ce-java17/lib/static/linux-amd64/glibc/libfdlibm.a /usr/lib64/graalvm/graalvm22-ce-java17/lib/static/linux-amd64/glibc/libzip.a /usr/lib64/graalvm/graalvm22-ce-java17/lib/svm/clibraries/linux-amd64/libjvm.a -v -L/tmp/SVM-1043361363098864337 -L/usr/lib64/graalvm/graalvm22-ce-java17/lib/static/linux-amd64/glibc -L/usr/lib64/graalvm/graalvm22-ce-java17/lib/svm/clibraries/linux-amd64 -lpthread -ldl -lz -lrt

Linker command output:
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,fortran,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl --disable-libmpx --enable-offload-targets=nvptx-none --without-cuda-driver --enable-gnu-indirect-function --enable-cet --with-tune=generic --with-arch_32=x86-64 --build=x86_64-redhat-linux
Thread model: posix
gcc version 8.5.0 20210514 (Red Hat 8.5.0-4.0.2) (GCC)
COMPILER_PATH=/usr/libexec/gcc/x86_64-redhat-linux/8/:/usr/libexec/gcc/x86_64-redhat-linux/8/:/usr/libexec/gcc/x86_64-redhat-linux/:/usr/lib/gcc/x86_64-redhat-linux/8/:/usr/lib/gcc/x86_64-redhat-linux/
LIBRARY_PATH=/usr/lib/gcc/x86_64-redhat-linux/8/:/usr/lib/gcc/x86_64-redhat-linux/8/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-redhat-linux/8/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-z' 'noexecstack' '-o' '/hello/hello' '-v' '-L/tmp/SVM-1043361363098864337' '-L/usr/lib64/graalvm/graalvm22-ce-java17/lib/static/linux-amd64/glibc' '-L/usr/lib64/graalvm/graalvm22-ce-java17/lib/svm/clibraries/linux-amd64' '-mtune=generic' '-march=x86-64'
 /usr/libexec/gcc/x86_64-redhat-linux/8/collect2 -plugin /usr/libexec/gcc/x86_64-redhat-linux/8/liblto_plugin.so -plugin-opt=/usr/libexec/gcc/x86_64-redhat-linux/8/lto-wrapper -plugin-opt=-fresolution=/tmp/cc6veW9s.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --build-id --no-add-needed --eh-frame-hdr --hash-style=gnu -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o /hello/hello -z noexecstack /usr/lib/gcc/x86_64-redhat-linux/8/../../../../lib64/crt1.o /usr/lib/gcc/x86_64-redhat-linux/8/../../../../lib64/crti.o /usr/lib/gcc/x86_64-redhat-linux/8/crtbegin.o -L/tmp/SVM-1043361363098864337 -L/usr/lib64/graalvm/graalvm22-ce-java17/lib/static/linux-amd64/glibc -L/usr/lib64/graalvm/graalvm22-ce-java17/lib/svm/clibraries/linux-amd64 -L/usr/lib/gcc/x86_64-redhat-linux/8 -L/usr/lib/gcc/x86_64-redhat-linux/8/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/8/../../.. --gc-sections --dynamic-list /tmp/SVM-1043361363098864337/exported_symbols.list --exclude-libs ALL -x hello.o /usr/lib64/graalvm/graalvm22-ce-java17/lib/svm/clibraries/linux-amd64/liblibchelper.a /usr/lib64/graalvm/graalvm22-ce-java17/lib/static/linux-amd64/glibc/libnet.a /usr/lib64/graalvm/graalvm22-ce-java17/lib/static/linux-amd64/glibc/libextnet.a /usr/lib64/graalvm/graalvm22-ce-java17/lib/static/linux-amd64/glibc/libnio.a /usr/lib64/graalvm/graalvm22-ce-java17/lib/static/linux-amd64/glibc/libjava.a /usr/lib64/graalvm/graalvm22-ce-java17/lib/static/linux-amd64/glibc/libfdlibm.a /usr/lib64/graalvm/graalvm22-ce-java17/lib/static/linux-amd64/glibc/libzip.a /usr/lib64/graalvm/graalvm22-ce-java17/lib/svm/clibraries/linux-amd64/libjvm.a -lpthread -ldl -lz -lrt -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-redhat-linux/8/crtend.o /usr/lib/gcc/x86_64-redhat-linux/8/../../../../lib64/crtn.o
hello.o:(.data+0x210): undefined reference to `Java_java_lang_PanwHooksNs_HookArgs0'
collect2: error: ld returned 1 exit status
	at com.oracle.svm.hosted.image.NativeImageViaCC.handleLinkerFailure(NativeImageViaCC.java:505)
	at com.oracle.svm.hosted.image.NativeImageViaCC.write(NativeImageViaCC.java:452)
	at com.oracle.svm.hosted.NativeImageGenerator.doRun(NativeImageGenerator.java:695)
	at com.oracle.svm.hosted.NativeImageGenerator.run(NativeImageGenerator.java:515)
	at com.oracle.svm.hosted.NativeImageGeneratorRunner.buildImage(NativeImageGeneratorRunner.java:407)
	at com.oracle.svm.hosted.NativeImageGeneratorRunner.build(NativeImageGeneratorRunner.java:585)
	at com.oracle.svm.hosted.NativeImageGeneratorRunner.main(NativeImageGeneratorRunner.java:128)
	at com.oracle.svm.hosted.NativeImageGeneratorRunner$JDK9Plus.main(NativeImageGeneratorRunner.java:615)
-----------------------------------------------------------------------------------------------
            3.5s (7.9% of total time) in 25 GCs | Peak RSS: 4.84GB | CPU load: 8.32
===============================================================================================
Failed generating 'hello' after 43.9s.
Error: Image build request failed with exit status 1

push ARM Graalvm image

How,

Currently, for AWS Lambda and Graalvm I'm using Docker ghcr.io/graalvm/graalvm-ce:latest.
But I need a arm64 based Docker image. How can I retrieve it? I don't see such tag

Able to build the spring boot app to executable in docker image, but unable to run.

Error:

./starter: /lib64/libc.so.6: version `GLIBC_2.32' not found (required by ./starter)

Base image: ghcr.io/graalvm/graalvm-ce:22.3.1

I am using spring native. In the pom.xml, this is my plugin config:

<plugin>
  <groupId>org.graalvm.buildtools</groupId>
  <artifactId>native-maven-plugin</artifactId>
</plugin>

The command i use to build it is mvnw native:compile -Pnative.

Is it because the difference in linux OS? In the docker image, the OS is Oracle Linux 9.1, but I am running the executable in the Redhat system.

If so, how can i make sure that the executable able to run in other Linux OS? I want it to be able to run on:

  1. Ubuntu Linux 22.04 LTS
  2. Red Hat Enterprise Linux 8.2

Windows docker image

Is it possible to have windows docker image? That would help a lot CIs build with graalvm for windows users

Problem with FastR in GraalVM docker container

Hi,
I have just pulled the Docker image (latest version) of GraalVM, then "gu install R" to install FastR successfully.
In the FastR interpreter (version 4.0.3), I type:
install.packages("devtools")
After long time (>1h) of installation I have many errors that I could resolve some of those by install the following libraries in bash:
microdnf install gcc-gfortran bzip2 libxml2-devel
I tried again to install the package "devtools", and this time it remained 3 dependents packages impossible to install: "fs" "gert" and "usethis".

The error for "fs" package installation is:
**configure: error: in '/tmp/RtmpkN9qMZ/R.INSTALL1uvvgcvtz68m/fs/src/libuv-1.38.1':
configure: error: cannot run C compiled programs.
If you meant to cross compile, use '--host'.
See 'config.log' for more details
make: *** [Makevars:31: libuv-1.38.1/Makefile] Error 1
ERROR: compilation failed for package ‘fs’

  • removing ‘/opt/graalvm-ce-java11-21.2.0/languages/R/library/fs’**

The error for "gert" package installation is:
**Error in polyglot evaluation : /opt/graalvm-ce-java11-21.2.0/languages/R/library/00LOCK-gert/00new/gert
/libs/gert.so: undefined symbol: Rf_warningcall_immediate
ERROR: loading failed

  • removing ‘/opt/graalvm-ce-java11-21.2.0/languages/R/library/gert’**

So the packages "usethis" and then "devtools" could not be installed because of not complete dependent packages above.
Please help me to resolve this issue.
Thank you very much.
Best regards

Unable to build truffleruby/Dockerfile.ol-* files with podman

Example:

$ podman build --build-arg GRAALVM_VERSION=21.3.0 -f Dockerfile.ol8 .
STEP 1: FROM container-registry.oracle.com/os/oraclelinux:7-slim:8-slim
Error: error creating build container: error resolving local image "container-registry.oracle.com/os/oraclelinux:7-slim:8-slim": cannot parse input: "container-registry.oracle.com/os/oraclelinux:7-slim:8-slim": invalid reference format

The Dockerfile.debian file does build successfully.

gcc and make should be remove for the truffleruby-slim image

From #31 (comment)
The fix for #31 seems to have made the image significantly bigger.

I think it should be sufficient to merge these two RUN into one, and uninstall gcc make openssl-devel after:
https://github.com/graalvm/container/blob/master/truffleruby/Dockerfile.ol8-slim#L17-L25
In other words, we only need the packages zlib openssl-devel glibc-langpack-en installed for the slim image, as it was before 2cb1a08#diff-84f2742614cf3abb76ac4f64e9b684a87dfb410468d883020f867f141605bd63

Looking at docker images for slim truffleruby images we can see the increase:

REPOSITORY                                    TAG                  IMAGE ID      CREATED        SIZE
ghcr.io/graalvm/truffleruby                   ol8-slim-22.3.0      72c050e04efe  4 weeks ago    627 MB
ghcr.io/graalvm/truffleruby                   slim-22.3.0          cefe2df96216  4 weeks ago    641 MB
ghcr.io/graalvm/truffleruby                   ol7-slim-22.3.0      d0a4ce0f9058  4 weeks ago    755 MB

ghcr.io/graalvm/truffleruby                   slim (21.3)          b7acad548949  13 months ago  400 MB

Missing locales in ol8 image 

bash-4.4# locale
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"

Which results (I think) in the wrong locale being used in Java.

Fixed with:

bash-4.4# microdnf install glibc-langpack-en
...
bash-4.4# locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"

Where is the docker file for ghcr.io/graalvm/graalvm-ce:latest

We where used to use yum to install additional tools into the container. Before we where using the version hosted on docker-hub. Now we switched to use ghcr.io/graalvm/graalvm-ce:latest (since the docker-hub one is gone).

Running

$ docker run -ti ghcr.io/graalvm/graalvm-ce:latest uname -a
Linux 6761594d38d0 5.4.0-60-generic #67-Ubuntu SMP Tue Jan 5 18:31:36 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Tells me that it's now using Ubuntu. Where can I find the Dockerfile for ghcr.io/graalvm/graalvm-ce:latest?

VMError$HostedError: java.io.IOException: Cannot run program "/tmp/SVM-/JNIHeaderDirective in ol8-java11-22.3.0

Describe the issue
$Subject

This is a jar generated from a jvm language called ballerina.It runs just fine with the container ol8-java11-22.2.0. But when its bumped to the newest version which is ol8-java11-22.3.0, native build shows the following error in the gist. The native build with the same jar and same flags works just fine in my local computer with graalvm 22.3.0. (Ubuntu 20.04).

https://gist.github.com/xlight05/e7794a603f9dedcd31ecb67533c81852

Steps to reproduce the issue
I hacked a sample app for you guys to debug this issue.

git clone https://github.com/xlight05/graal-container-debug
docker build -t test-graal-debug .
docker run test-graal-debug

You can simpy change the FROM ghcr.io/graalvm/native-image:ol8-java11-22.3.0 to FROM ghcr.io/graalvm/native-image:ol8-java11-22.2.0 and build again and the native build should work just fine.

Appreciate your help on this issue. Thanks in advance ;)

Java not found on linux/arm64 java17-21.3.0 image

We are building scala sbt images from this image and have an issue that only appears on the arm64 version for java17, the java11 and java8 images don't have this issue

/usr/local/bin/scala: line 23: /opt/graalvm-ce-java17-21.3.0//bin/java: No such file or directory

I have no arm64 system at my disposal so I can't properly debug this

Failed build
https://github.com/hseeberger/scala-sbt/runs/4019833714?check_suite_focus=true

Successful build with arm64 disabled (only for java17)
https://github.com/hseeberger/scala-sbt/runs/4020249783?check_suite_focus=true

Unable to run "gu" in graalvm-community images

Hi,

Seeing that the graalvm-ce images are deprecated, I tried to use graalvm-community images instead.
Unfortunately, the "gu" command is not working at all in these images, as demonstrated in the snippet below.

$ docker run -it --rm ghcr.io/graalvm/graalvm-community:21.0.1-ol9 bash
bash-5.1# gu install wasm
bash: /usr/local/bin/gu: Permission denied
bash-5.1# chmod +x /usr/local/bin/gu
bash-5.1# gu install wasm
/usr/local/bin/gu: line 8: /opt/graalvm-community-java21/bin/gu: No such file or directory
bash-5.1#

Two problems :

  • The "gu-wrapper.sh" script, which is copied to /usr/local/bin/gu by the dockerfile, is not executable.
  • The gu binary is completely missing from the JAVA_HOME/bin folder

This seems to suggest that one step of this RUN command failed silently during the build, before it reached the chmod : https://github.com/graalvm/container/blob/master/graalvm-community/Dockerfile.ol9-java17#L33-L47

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.