munishchouhan
commented
4 years ago @starkgate Thanks for reporting the issue We will look into it and update you
Closed starkgate closed 4 years ago
munishchouhan
commented
4 years ago @starkgate Thanks for reporting the issue We will look into it and update you
munishchouhan
commented
4 years ago @starkgate please clarify Are you trying to build native-image of helloworld.java? or you are trying to build native-image component of GraalVM?
starkgate
commented
4 years ago I'm trying to build a native-image of helloworld.java. I've already built native-image before with mx build in the graal/substratevm folder.
munishchouhan
commented
4 years ago to create Native Image of helloworld.java
you have to use this command:
native-image HelloWorld
gradinac
commented
4 years ago Hey @starkgate!
Have you built GraalVM on Alpine, or is it a build on another OS?
We currently do not support building/running GraalVM itself on Alpine. However, we support creating static native-images linked against musl (as you've already specified in the options) that can be run on Alpine/in a FROM scratch container.
Since 20.2, the way musl static linking works has been changed. You first have to setup the environment on your host so that musl-gcc is exposed on the path and has all the required libraries available. Here's a guide on how to do that: https://github.com/oracle/graal/blob/master/substratevm/StaticImages.md
Once you've done the setup, you can add --static --libc=musl to your native-image build.
Let me know if you have any issues with it
starkgate
commented
4 years ago Have you built GraalVM on Alpine, or is it a build on another OS?
Yes. Built on Alpine.
Once you've done the setup, you can add --static --libc=musl to your native-image build.
Is this different from -H:UseLibC=musl? ie could the crash be caused by the wrong option instead of Alpine itself?
However, we support creating static native-images linked against musl
The problem is that I need it to run on Alpine. I've successfully built native-images linked against musl on a normal Ubuntu system. But the end goal of my project is to compile Java apps in an AoT fashion using GraalVM and musl. The trick is that the compilation must be made with SCONE (tl;dr a wrapper for GCC that uses Intel's SGX instructions, only available on Alpine dockers). Hence the need to compile GraalVM on Alpine.
munishchouhan
commented
4 years ago @starkgate for docker you can use graalvm docker image Something like this:
from oracle/graalvm-ce RUN gu install native-image COPY HelloWorld.class . RUN native-image HelloWorld CMD ./helloworld
starkgate
commented
4 years ago @starkgate for docker you can use graalvm docker image Something like this:
from oracle/graalvm-ce RUN gu install native-image COPY HelloWorld.class . RUN native-image HelloWorld CMD ./helloworld
I don't understand what you mean. Run this docker from the Alpine docker? Wouldn't it be compiled with libc instead of musl then?
gradinac
commented
4 years ago @starkgate the failure you've encountered comes from this code:
UserError.guarantee(!Platform.includedIn(InternalPlatform.PLATFORM_JNI.class),
"Building images for %s%s requires static JDK libraries.%Use the JDK from %s%n%s",
ImageSingletons.lookup(Platform.class).getClass().getName(),
libCMessage,
jdkDownloadURL,
hint);The error you were supposed to see is the one in the above code, but when I edited this the last time, I seem to have written % instead of %n, sorry for that! :) I will make a PR to rectify it.
The true error shows that you do not have the static JDK libraries available for your selected libc (musl). Which version of the labsjdk are you using? For the newer lalbsjdk 11 version 20.2+, the static library layout has changed. Since you're building GraalVM, I assume you have mx - you can run mx fetch-jdk --to /path/where/to/save/it to quickly download the newest JDK (it will show a menu where you can select labsjdk 11)
Also, -H:UseMuslC should not even be available on 20.2, I'm not sure how you can see it, which branch are you building from?
starkgate
commented
4 years ago @gradinac Thank you so much. I'll give this a try soon. I'm building from release/graal-vm/20.2.
Edit: Afaik, pre-built JDKs don't work in a musl environment, that's the reason I built even the JDK manually. Here's the error when trying to run java for instance: Path in JAVA_HOME is not pointing to a JDK (2: No such file or directory): /mnt/shared/fetch-jdk/labsjdk-ce-11-jvmci-20.2-b03. It complains because it can't find the libc so files.
The next question would be how to compile the JDK so that these static libraries are available?
I can also confirm that I get the exact same log no matter which of the 2 musl options I use:
bash-4.4# mx native-image -H:+ReportExceptionStackTraces --static -H:UseLibC="musl" -cp /mnt/shared/native-image-sandbox hello.HelloWorld
[hello.helloworld:824] classlist: 3,846.80 ms, 0.96 GB
[hello.helloworld:824] (cap): 14.19 ms, 0.96 GB
[hello.helloworld:824] setup: 1,535.85 ms, 0.96 GB
Fatal error:java.util.UnknownFormatConversionException: Conversion = 'U'
at java.base/java.util.Formatter$FormatSpecifier.conversion(Formatter.java:2839)
at java.base/java.util.Formatter$FormatSpecifier.<init>(Formatter.java:2865)
at java.base/java.util.Formatter.parse(Formatter.java:2713)
at java.base/java.util.Formatter.format(Formatter.java:2655)
at java.base/java.util.Formatter.format(Formatter.java:2609)
at java.base/java.lang.String.format(String.java:2897)
at com.oracle.svm.core.util.UserError.guarantee(UserError.java:92)
at com.oracle.svm.hosted.c.NativeLibraries.initCLibraryPath(NativeLibraries.java:334)
at com.oracle.svm.hosted.c.NativeLibraries.<init>(NativeLibraries.java:256)
at com.oracle.svm.hosted.NativeImageGenerator.setupNativeLibraries(NativeImageGenerator.java:1034)
at com.oracle.svm.hosted.NativeImageGenerator.setupNativeImage(NativeImageGenerator.java:868)
at com.oracle.svm.hosted.NativeImageGenerator.doRun(NativeImageGenerator.java:553)
at com.oracle.svm.hosted.NativeImageGenerator.lambda$run$0(NativeImageGenerator.java:468)
at java.base/java.util.concurrent.ForkJoinTask$AdaptedRunnableAction.exec(ForkJoinTask.java:1407)
at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)
Error: Image build request failed with exit status 1
bash-4.4# mx native-image -H:+ReportExceptionStackTraces --static --libc=musl -cp /mnt/shared/native-image-sandbox hello.HelloWorld
[hello.helloworld:1096] classlist: 3,593.11 ms, 0.96 GB
[hello.helloworld:1096] (cap): 15.58 ms, 0.96 GB
[hello.helloworld:1096] setup: 1,203.51 ms, 0.96 GB
Fatal error:java.util.UnknownFormatConversionException: Conversion = 'U'
at java.base/java.util.Formatter$FormatSpecifier.conversion(Formatter.java:2839)
at java.base/java.util.Formatter$FormatSpecifier.<init>(Formatter.java:2865)
at java.base/java.util.Formatter.parse(Formatter.java:2713)
at java.base/java.util.Formatter.format(Formatter.java:2655)
at java.base/java.util.Formatter.format(Formatter.java:2609)
at java.base/java.lang.String.format(String.java:2897)
at com.oracle.svm.core.util.UserError.guarantee(UserError.java:92)
at com.oracle.svm.hosted.c.NativeLibraries.initCLibraryPath(NativeLibraries.java:334)
at com.oracle.svm.hosted.c.NativeLibraries.<init>(NativeLibraries.java:256)
at com.oracle.svm.hosted.NativeImageGenerator.setupNativeLibraries(NativeImageGenerator.java:1034)
at com.oracle.svm.hosted.NativeImageGenerator.setupNativeImage(NativeImageGenerator.java:868)
at com.oracle.svm.hosted.NativeImageGenerator.doRun(NativeImageGenerator.java:553)
at com.oracle.svm.hosted.NativeImageGenerator.lambda$run$0(NativeImageGenerator.java:468)
at java.base/java.util.concurrent.ForkJoinTask$AdaptedRunnableAction.exec(ForkJoinTask.java:1407)
at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)
Error: Image build request failed with exit status 1
@starkgate No problem at all! :)
The library shuffle happens during the build in our CI, that's when the static libraries are put in their correct place in the layout.
The layout is structured like this: $JAVA_HOME/lib/static/<os>-<arch>/. For Linux, there's an additional folder: $JAVA_HOME/lib/static/<os>-<arch>/<libc> . When compiling against musl on linux-amd64, the path that gets searched is: $JAVA_HOME/lib/static/linux-amd64/musl.
Are you using a glibc compatibility layer inside your Alpine container, or are you compiling everything against musl? If you are compiling the JDK against glibc, you won't have the musl libraries available - you'd need to compile it once more against musl and get the libraries from there. In any case, you can manually create the folders as specified in the above layout and put the libraries there, just make sure that the ones you do put are the exact libc they were compiled against
Edit: In case you can't find static libraries in the default JDK build, I think they are located in $JAVA_HOME/lib, you can grab all *.a files when moving them
starkgate
commented
4 years ago I'm compiling everything against musl, no glibc is involved.
Just to confirm, this is the command I should run to move the libraries?
mv $JAVA_HOME/lib/* $JAVA_HOME/lib/static/linux-amd64/musl
I tried this, it didn't change anything to the error, this time with mx native-image -H:+ReportExceptionStackTraces --static --libc=musl -cp /mnt/shared/native-image-sandbox hello.HelloWorld. I do see the musl related libs though.
bash-4.4# ls $JAVA_HOME/lib/static/linux-amd64/musl
apk libawt_headless.so libj2gss.so libjimage.so libnio.so libtls.so.16.0.1 modules
classlist libawt_xawt.so libj2pcsc.a libjli.a libprefs.a libunpack.so psfont.properties.ja
ct.sym libc.musl-x86_64.so.1 libj2pcsc.so libjsig.a libprefs.so libuuid.so.1 psfontj2d.properties
firmware libc.scone-x86_64.so.1 libj2pkcs11.a libjsig.so librmi.so libuuid.so.1.3.0 security
jexec libcrypto.so.42 libj2pkcs11.so libjsound.so libsaproc.so libverify.a server
jfr libcrypto.so.42.0.0 libjaas.a liblcms.so libsctp.a libverify.so src.zip
jli libdt_socket.so libjaas.so libmanagement.so libsctp.so libz.a static
jrt-fs.jar libextnet.a libjava.a libmanagement_agent.so libsplashscreen.so libz.so tzdb.dat
jspawnhelper libextnet.so libjava.so libmanagement_ext.so libssl.so.44 libz.so.1
jvm.cfg libfdlibm.a libjavajpeg.so libmlib_image.so libssl.so.44.0.1 libz.so.1.2.11
ld-musl-x86_64.so.1 libfontmanager.so libjawt.so libnet.a libsunec.a libzip.a
libattach.so libinstrument.so libjdwp.so libnet.so libsunec.so libzip.so
libawt.so libj2gss.a libjimage.a libnio.a libtls.so.16 mdevOh, no, not everything! Only the .a files should have been moved! You should move everything back, and then do:
mv $JAVA_HOME/lib/*.a $JAVA_HOME/lib/static/linux-amd64/muslYou should also rebuild GraalVM after doing this. If you want to skip the build, you can cp -r $JAVA_HOME/lib/static $GRAALVM_HOME/lib/
starkgate
commented
4 years ago I'm sorry this is so tedious, I'm not used to this. Here's what I did:
mv $JAVA_HOME/lib/*.a $JAVA_HOME/lib/static/linux-amd64/musl
export GRAALVM_HOME=/mnt/shared/graal/substratevm/svmbuild/vm # this is where the native-image executable is, I assume it's the right place
cp -r $JAVA_HOME/lib/static $GRAALVM_HOME/lib/The error I get now is different from before (yay!) and too long for github: https://pastebin.com/BCPfcGrC
gradinac
commented
4 years ago There is nothing to be sorry about, you are exploring an unsupported platform, there's bound to be a ton of errors along the way! :)
These errors come from the linker, it is complaining about the clibraries that we have available. Did you build the entire GraalVM on your machine using the exact same gcc that you've used for the JDK, or did you paste them from a different build? Perhaps we require some additional flags when building on musl? You mentioned you want to run on Alpine due to a special gcc wrapper, did you build GraalVM with that wrapper also? I think we, by default, build clibraries using gcc. The easiest way to trick our build to use your wrapper is to make it available as gcc on path, while moving gcc somewhere else where the wrapper can still find it
starkgate
commented
4 years ago Alright. Gave this another try, this time on vanilla Alpine 3.11 (no SCONE, just musl). Everything was built on that system, OpenJDK and GraalVM. Full log: https://pastebin.com/pdW3usTq
/usr/lib/gcc/x86_64-alpine-linux-musl/9.3.0/../../../../x86_64-alpine-linux-musl/bin/ld: /tmp/SVM-9501043139235787696/hello.helloworld.o: warning: relocation in read-only section `.svm_heap'
/usr/lib/gcc/x86_64-alpine-linux-musl/9.3.0/../../../../x86_64-alpine-linux-musl/bin/ld: read-only segment has dynamic relocations
collect2: error: ld returned 1 exit statusDo you have the gold linker available inside the docker container (ld.gold)? If yes, you can add -H:+ForceNoROSectionRelocations, that should get rid of that error.
starkgate
commented
4 years ago Man, I'd never have been able to come up with this. Thanks. New error, this time I think it's a bug with graal. I'm not sure if I should open a new issue for this. It looks like some of gold's options (in particular --no-dynamic-linker) aren't consistent with ld and graal isn't accounting for that.
/usr/lib/gcc/x86_64-alpine-linux-musl/9.3.0/../../../../x86_64-alpine-linux-musl/bin/ld.gold: --no-dynamic-linker: unknown option
/usr/lib/gcc/x86_64-alpine-linux-musl/9.3.0/../../../../x86_64-alpine-linux-musl/bin/ld.gold: use the --help option for usage information
collect2: error: ld returned 1 exit status
at com.oracle.svm.hosted.image.NativeBootImageViaCC.handleLinkerFailure(NativeBootImageViaCC.java:459)
at com.oracle.svm.hosted.image.NativeBootImageViaCC.write(NativeBootImageViaCC.java:434)
at com.oracle.svm.hosted.NativeImageGenerator.doRun(NativeImageGenerator.java:677)
at com.oracle.svm.hosted.NativeImageGenerator.lambda$run$0(NativeImageGenerator.java:468)
at java.base/java.util.concurrent.ForkJoinTask$AdaptedRunnableAction.exec(ForkJoinTask.java:1407)
at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)
Error: Image build request failed with exit status 1ld.gold --version
GNU gold (GNU Binutils 2.34) 1.16@gradinac Any idea?
gradinac
commented
4 years ago Hey @starkgate, sorry for the late answer on this. Is that an option you are passing in manually? If not, I suspect gcc might be passing this option in that case. Could you post the output of your build, with the addition of the following option: -H:Log=InvokeCC? It should provide us with the underlying command. If we don't see the option, then it's most likely something on the gcc side of things, but we'll have to verify it (I don't think I've seen a reference to that option in our code)
starkgate
commented
4 years ago Hope this is what you want: https://pastebin.com/V2dJ38x5
mx native-image \
-H:+ReportExceptionStackTraces \
--static \
--libc=musl \
-H:+DumpTargetInfo \
-H:CCompilerOption=--verbose \
-H:+ForceNoROSectionRelocations \
-H:Log=InvokedCC \
$@ \
-cp "$TEST_DIR" hello.HelloWorldThat is good, we have the following command that was executed:
/usr/bin/musl-gcc --verbose -z noexecstack -fuse-ld=gold -Wl,--rosegment -Wl,--gc-sections -Wl,-x -o /mnt/shared/AoTandSCONE/scripts/graal/substratevm/hello.helloworld /tmp/SVM-4600335603115752879/hello.helloworld.o /mnt/shared/AoTandSCONE/scripts/graal/substratevm/mxbuild/linux-amd64/SVM_HOSTED_NATIVE/linux-amd64/liblibchelper.a /mnt/shared/AoTandSCONE/scripts/graal/sdk/mxbuild/linux-amd64/GRAALVM_AA6F4A609A_JAVA11/graalvm-aa6f4a609a-java11-20.2.1-dev/lib/static/linux-amd64/musl/libnet.a /mnt/shared/AoTandSCONE/scripts/graal/substratevm/mxbuild/linux-amd64/SVM_HOSTED_NATIVE/linux-amd64/libffi.a /mnt/shared/AoTandSCONE/scripts/graal/sdk/mxbuild/linux-amd64/GRAALVM_AA6F4A609A_JAVA11/graalvm-aa6f4a609a-java11-20.2.1-dev/lib/static/linux-amd64/musl/libnio.a /mnt/shared/AoTandSCONE/scripts/graal/sdk/mxbuild/linux-amd64/GRAALVM_AA6F4A609A_JAVA11/graalvm-aa6f4a609a-java11-20.2.1-dev/lib/static/linux-amd64/musl/libjava.a /mnt/shared/AoTandSCONE/scripts/graal/sdk/mxbuild/linux-amd64/GRAALVM_AA6F4A609A_JAVA11/graalvm-aa6f4a609a-java11-20.2.1-dev/lib/static/linux-amd64/musl/libfdlibm.a /mnt/shared/AoTandSCONE/scripts/graal/sdk/mxbuild/linux-amd64/GRAALVM_AA6F4A609A_JAVA11/graalvm-aa6f4a609a-java11-20.2.1-dev/lib/static/linux-amd64/musl/libzip.a /mnt/shared/AoTandSCONE/scripts/graal/substratevm/mxbuild/linux-amd64/SVM_HOSTED_NATIVE/linux-amd64/libjvm.a -static -v -L/tmp/SVM-4600335603115752879 -L/mnt/shared/AoTandSCONE/scripts/graal/sdk/mxbuild/linux-amd64/GRAALVM_AA6F4A609A_JAVA11/graalvm-aa6f4a609a-java11-20.2.1-dev/lib/static/linux-amd64/musl -L/mnt/shared/AoTandSCONE/scripts/graal/sdk/mxbuild/linux-amd64/GRAALVM_AA6F4A609A_JAVA11/graalvm-aa6f4a609a-java11-20.2.1-dev/lib/svm/clibraries/linux-amd64 -L/mnt/shared/AoTandSCONE/scripts/graal/substratevm/mxbuild/linux-amd64/SVM_HOSTED_NATIVE/linux-amd64 -lpthread -ldl -lz -lrtgcc internally invokes collect2 that takes care of calling the appropriate linker. The culprit only appears in the collect2 command. After digging a bit further, it seems like ld.gold does not support the --no-dynamic-linker option. A breakdown of what happens is:
GCC is instructed to create a static executable. Notice the -enable-default-pie option - it will try to make it position independent by default. A position independent executable can be loaded at any address and therefor does not require additional patching to be done by the dynamic linker. Since the dynamic linker is no longer needed, gcc then appends the --no-dynamic-linker option. You can see this by dumping gcc's spec file with musl-gcc -dumpspecs > specs. Under the link section, you can see the following: %{static-pie:-static -pie --no-dynamic-linker -z text}
If you do not care about having your application require a dynamic linker to be loaded, you can add -H:NativeLinkerOption='-no-pie'. The root of this problem (relocations in read only section) is why the -H:+ForceROSectionRelocations flag exists - we do plan to address this at some point
starkgate
commented
4 years ago My god, it works. At least with the hello world, let's hope nothing more pops up when compiling more complex apps. Thank you for all the help thus far, it's truly appreciated!
gradinac
commented
4 years ago No problem at all! I'm glad to hear it works :) Hopefully, once those issues are addressed this will be a lot easier so that one day we can also support that platform out of the box.
starkgate
commented
4 years ago @gradinac If I run mx --env ni-ce build from graal/vm, where should I put the static libraries? I'm getting the same error:java.util.UnknownFormatConversionException as before, despite graal/substratevm working fine. The static libs are in $JAVA_HOME/lib/static/linux-amd64/musl.
gradinac
commented
4 years ago The UnknownFormatConversionException should be fixed in https://github.com/oracle/graal/commit/e555fca6de15fcd4d2bbbbb4e707b7496ee15b6e.
As for the issue you are hitting, if I understood you correctly: cd substratevm && mx build works but cd vm && mx --env ni-ce build fails?
The exact same code should run for the static library discovery. Could you verify that JAVA_HOME is indeed pointing to the proper JDK with the fixed library layout? Once you do that, we can try to force mx to use the JAVA_HOME JDK using mx --java-home $JAVA_HOME ...
starkgate
commented
4 years ago As for the issue you are hitting, if I understood you correctly: cd substratevm && mx build works but cd vm && mx --env ni-ce build fails?
Exactly. Tried mx --java-home $JAVA_HOME --env ni-ce build too, no change.
Here's the relevant part of the log. I could recompile Graal with e555fca to get the actual error message, but it wouldn't tell me much more.
Building libnative-image-agent.so.image... [/mnt/shared/AoTandSCONE/scripts/graal/sdk/mxbuild/linux-amd64/libnative-image-agent.so.image/libnative-image-agent.so does not exist]
[libnative-image-agent:9248] classlist: 3,605.01 ms, 0.96 GB
WARNING: Using an older version of the labsjdk-11.
[libnative-image-agent:9248] (cap): 9.72 ms, 0.96 GB
[libnative-image-agent:9248] setup: 861.21 ms, 0.96 GB
Fatal error:java.util.UnknownFormatConversionException: Conversion = 'U'
at java.base/java.util.Formatter$FormatSpecifier.conversion(Formatter.java:2839)
at java.base/java.util.Formatter$FormatSpecifier.<init>(Formatter.java:2865)
at java.base/java.util.Formatter.parse(Formatter.java:2713)
at java.base/java.util.Formatter.format(Formatter.java:2655)
at java.base/java.util.Formatter.format(Formatter.java:2609)
at java.base/java.lang.String.format(String.java:2897)
at com.oracle.svm.core.util.UserError.guarantee(UserError.java:92)
at com.oracle.svm.hosted.c.NativeLibraries.initCLibraryPath(NativeLibraries.java:334)
at com.oracle.svm.hosted.c.NativeLibraries.<init>(NativeLibraries.java:256)
at com.oracle.svm.hosted.NativeImageGenerator.setupNativeLibraries(NativeImageGenerator.java:1034)
at com.oracle.svm.hosted.NativeImageGenerator.setupNativeImage(NativeImageGenerator.java:868)
at com.oracle.svm.hosted.NativeImageGenerator.doRun(NativeImageGenerator.java:553)
at com.oracle.svm.hosted.NativeImageGenerator.lambda$run$0(NativeImageGenerator.java:468)
at java.base/java.util.concurrent.ForkJoinTask$AdaptedRunnableAction.exec(ForkJoinTask.java:1407)
at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)
Error: Image build request failed with exit status 1
Building libnative-image-agent.so.image failed
1 build tasks failedHmm, perhaps it's due to the difference in the environment - is this the build you've been using for your hello world native-image? I suspect this doesn't occur due to the difference in the suites - to verify that, you can run NATIVE_IMAGES=lib:native-image-agent mx build from substratevm
I think something else happens here - we currently do not support running GraalVM on anything other than glibc-based Linux systems. As such, the default libc selected happens to be glibc. The native-image-agent build will try and find static/linux-amd64/glibc and fail. If I recall correctly, you are not using a glibc compat layer. If that is the case, as a workaround, you can do pushd $JAVA_HOME/lib/static/linux-amd64 && cp -r musl glibc && popd. This will result in native-image picking up the appropriate libraries. Let me know if any more issues arise with that change
starkgate
commented
4 years ago Hmm, perhaps it's due to the difference in the environment - is this the build you've been using for your hello world native-image? I suspect this doesn't occur due to the difference in the suites - to verify that, you can run
NATIVE_IMAGES=lib:native-image-agent mx buildfromsubstratevm
This does indeed cause the same crash outlined before in substratevm.
If that is the case, as a workaround, you can do
pushd $JAVA_HOME/static/linux-amd64 && cp -r musl glibc && popd. This will result in native-image picking up the appropriate libraries. Let me know if any more issues arise with that change
I assume you meant $JAVA_HOME/lib/static/linux-amd64. The same thing happens after that change. Here's the output of the tree command:
tree $JAVA_HOME/lib
/mnt/shared/AoTandSCONE/scripts/custom-openjdk11/build/labsjdks/release/labsjdk-ce-11.0.8-jvmci-jvmci-20.2-b03/lib
├── classlist
├── ct.sym
├── jexec
├── jfr
│ ├── default.jfc
│ └── profile.jfc
├── jli
│ └── libjli.so
├── jrt-fs.jar
├── jspawnhelper
├── jvm.cfg
├── libattach.so
├── libawt.so
├── libawt_headless.so
├── libawt_xawt.so
├── libdt_socket.so
├── libextnet.so
├── libfontmanager.so
├── libinstrument.so
├── libj2gss.so
├── libj2pcsc.so
├── libj2pkcs11.so
├── libjaas.so
├── libjava.so
├── libjavajpeg.so
├── libjawt.so
├── libjdwp.so
├── libjimage.so
├── libjsig.so
├── libjsound.so
├── liblcms.so
├── libmanagement.so
├── libmanagement_agent.so
├── libmanagement_ext.so
├── libmlib_image.so
├── libnet.so
├── libnio.so
├── libprefs.so
├── librmi.so
├── libsaproc.so
├── libsctp.so
├── libsplashscreen.so
├── libsunec.so
├── libunpack.so
├── libverify.so
├── libzip.so
├── modules
├── psfont.properties.ja
├── psfontj2d.properties
├── security
│ ├── blacklisted.certs
│ ├── cacerts
│ ├── default.policy
│ └── public_suffix_list.dat
├── server
│ ├── Xusage.txt
│ ├── libjsig.so
│ └── libjvm.so
├── src.zip
├── static
│ └── linux-amd64
│ ├── glibc
│ │ ├── libextnet.a
│ │ ├── libfdlibm.a
│ │ ├── libj2gss.a
│ │ ├── libj2pcsc.a
│ │ ├── libj2pkcs11.a
│ │ ├── libjaas.a
│ │ ├── libjava.a
│ │ ├── libjimage.a
│ │ ├── libjli.a
│ │ ├── libjsig.a
│ │ ├── libnet.a
│ │ ├── libnio.a
│ │ ├── libprefs.a
│ │ ├── libsctp.a
│ │ ├── libsunec.a
│ │ ├── libverify.a
│ │ └── libzip.a
│ └── musl
│ ├── libextnet.a
│ ├── libfdlibm.a
│ ├── libj2gss.a
│ ├── libj2pcsc.a
│ ├── libj2pkcs11.a
│ ├── libjaas.a
│ ├── libjava.a
│ ├── libjimage.a
│ ├── libjli.a
│ ├── libjsig.a
│ ├── libnet.a
│ ├── libnio.a
│ ├── libprefs.a
│ ├── libsctp.a
│ ├── libsunec.a
│ ├── libverify.a
│ └── libzip.a
└── tzdb.datYou are correct, my bad - I've edited the above comment to reflect the proper path :)
Hmm, could you fix the error at com.oracle.svm.hosted.c.NativeLibraries.initCLibraryPath(NativeLibraries.java:334)? You can do that by replacing %U in that string with %nU - this should give us the proper error message.
starkgate
commented
4 years ago Here's the proper error message:
Building libnative-image-agent.so.image... [dependency JVMTI_AGENT_BASE updated]
[libnative-image-agent:13730] classlist: 3,696.64 ms, 0.96 GB
WARNING: Using an older version of the labsjdk-11.
[libnative-image-agent:13730] (cap): 9.96 ms, 0.96 GB
[libnative-image-agent:13730] setup: 931.17 ms, 0.96 GB
Error: Building images for org.graalvm.nativeimage.Platform$LINUX_AMD64(target libc: glibc) requires static JDK libraries.
Use the JDK from https://github.com/graalvm/labs-openjdk-11/releases
Missing libraries:java, nio, net, zip
Error: Use -H:+ReportExceptionStackTraces to print stacktrace of underlying exception
Error: Image build request failed with exit status 1This warning: WARNING: Using an older version of the labsjdk-11. suggests that it didn't find the folder with the static libraries that it was looking for. The logic for searching the libraries is here: com.oracle.svm.hosted.c.NativeLibraries#getPlatformDependentJDKStaticLibraryPath. Could you print the search path that it is looking for by replacing
if (Files.exists(platformDependentPath)) {
return platformDependentPath;
} else {
System.err.println("WARNING: Using an older version of the labsjdk-11.");
}with
if (Files.exists(platformDependentPath)) {
return platformDependentPath;
} else {
System.err.println("WARNING: Using an older version of the labsjdk-11.");
System.err.println("Searching for libraries at " + platformDependentPath);
}That way we should see what it's looking for and why it cannot find it
starkgate
commented
4 years ago Here's the result, always with cd vm && mx --java-home $JAVA_HOME --env ni-ce build: Searching for libraries at /mnt/shared/AoTandSCONE/scripts/graal/sdk/mxbuild/linux-amd64/GRAALVM_FECDE662FF_JAVA11_STAGE1/graalvm-fecde662ff-java11-20.2.1-dev/lib/static/linux-amd64/glibc
Placing the libraries there seems to work, but I've no idea why it's looking there in the first place. Next come a series of errors about GNU environment variables. I suppose this is because graal assumes here that glibc is used and doesn't apply any of the musl workarounds.
Building libnative-image-agent.so.image... [/mnt/shared/AoTandSCONE/scripts/graal/sdk/mxbuild/linux-amd64/libnative-image-agent.so.image/libnative-image-agent.so does not exist]
[libnative-image-agent:15784] classlist: 4,134.24 ms, 0.96 GB
[libnative-image-agent:15784] (cap): 662.41 ms, 0.96 GB
[libnative-image-agent:15784] setup: 1,553.07 ms, 0.96 GB
Error: Error compiling query code (in /tmp/SVM-9793302864193027106/PosixDirectives.c). Compiler command '/usr/bin/gcc -o /tmp/SVM-9793302864193027106/PosixDirectives /tmp/SVM-9793302864193027106/PosixDirectives.c ' output included error: /tmp/SVM-9793302864193027106/PosixDirectives.c:197:99: error: 'LC_PAPER' undeclared (first use in this function)
method com.oracle.svm.core.posix.headers.Mman.PROT_WRITE()
C file contents around line 197:
/tmp/SVM-9793302864193027106/PosixDirectives.c:196: printf("NativeCodeInfo:PosixDirectives:ConstantInfo:PROT_WRITE:PropertyInfo:value=%lX\n", PROT_WRITE);
/tmp/SVM-9793302864193027106/PosixDirectives.c:197: printf("NativeCodeInfo:PosixDirectives:ConstantInfo:LC_PAPER:PropertyInfo:size=%lu\n", sizeof(LC_PAPER));
/tmp/SVM-9793302864193027106/PosixDirectives.c:198: printf("NativeCodeInfo:PosixDirectives:ConstantInfo:LC_PAPER:PropertyInfo:signedness=$%s$\n", (IS_CONST_UNSIGNED(LC_PAPER)) ? "UNSIGNED" : "SIGNED");
...You are correct, although I find it very strange that the libraries did not end up being placed there. Perhaps we could try mx ... clean --all before building? As for the issue you are hitting now, you are correct - this is because it is using GNU only types on a musl based system. There are no clean workarounds for this at the moment, but if you just want it to run, you can change com/oracle/svm/core/posix/linux/libc/LibCFeature.java:49 from glibc to musl. This will instead search for musl static libraries and apply all the necessary logic for avoiding GNU specific types.
starkgate
commented
4 years ago Running mx --java-home $JAVA_HOME --env ni-ce clean --all seems to fix the missing libs problem. Modifying LibCFeature fixes the POSIX errors. On to the next error! I guess I need to add the --static option somewhere (and probably the other options like ForceNoROSectionRelocations too), the question is where?
Building libnative-image-agent.so.image... [/mnt/shared/AoTandSCONE/scripts/graal/sdk/mxbuild/linux-amd64/libnative-image-agent.so.image/libnative-image-agent.so does not exist]
[libnative-image-agent:20601] classlist: 4,306.84 ms, 0.96 GB
[libnative-image-agent:20601] setup: 526.41 ms, 0.96 GB
Error: Musl can only be used for statically linked executables.The first error you've encountered was probably something due to mx not figuring out that the JDK has changed and not updating the build accordingly. As for the next error, you can remove com/oracle/svm/core/posix/linux/libc/MuslLibC.java:38 the error condition from here. This check was in place to prevent users from accidentally generating dynamic native-images linked against musl. However, as you are running on a musl-based system, it should be fine
starkgate
commented
4 years ago libnative-image-agent compiles successfully with your changes, but actually running native-image causes a segfault. I don't want to use any more of your time with this, I'll just wait for Graal to openly support musl
The log:
bash-5.0# $JAVA_HOME/bin/native-image --no-server\
> --allow-incomplete-classpath --enable-https\
> --initialize-at-build-time=org.eclipse.jdt,org.apache.el.parser.SimpleNode,javax.servlet.jsp.JspFactory,org.apache.jasper.servlet.JasperInitializer,org.apache.jasper.runtime.JspFactoryImpl\
> -H:+JNI -H:+ReportUnsupportedElementsAtRuntime\
> -H:+ReportExceptionStackTraces -H:EnableURLProtocols=http,https,jar,jrt\
> -H:ConfigurationFileDirectories=$TOMCAT_STUFFED/target/\
> -H:ReflectionConfigurationFiles=$TOMCAT_STUFFED/tomcat-reflection.json\
> -H:ResourceConfigurationFiles=$TOMCAT_STUFFED/tomcat-resource.json\
> -H:JNIConfigurationFiles=$TOMCAT_STUFFED/tomcat-jni.json\
> --static \
> --libc=musl \
> -H:+DumpTargetInfo \
> -H:CCompilerOption=--verbose \
> -H:+ForceNoROSectionRelocations \
> -H:Log=InvokedCC \
> -H:NativeLinkerOption='-no-pie' \
> -jar $TOMCAT_STUFFED/target/tomcat-stuffed-1.0.jar
Segmentation fault (core dumped)
Describe the issue Native image builds of a simple hello world fail with
Fatal error:java.util.UnknownFormatConversionException: Conversion = 'U'.Steps to reproduce the issue Please include both build steps as well as run steps
Describe GraalVM and your environment:
More details HelloWorld.java:
Consider adding the
--native-image-infoand--verboseflags when building your native image and paste output below.Add any other information about the problem here. Especially important are stack traces or log output. Feel free to link to gists or to screenshots if necessary.