Native image fails to build on Windows and misreads system architecture

[nixin72]

Describe the issue
Native image fails to build on Windows and misreads system architecture.
Building a native image from the same jar file works fine on Linux.

Steps to reproduce the issue

1. git clone https://github.com/nixin72/shan
2. Download jar file into the repository
   • Easier to download jar file than getting all the Clojure build tools and building from scratch
3. native-image -jar .\shan.jar --no-fallback -H:ReflectionConfigurationFiles=reflect-config.json -H:Name=shan

Describe GraalVM and your environment:

• GraalVM version: GraalVM 21.2.0 Java 11 CE (Java Version 11.0.12+6-jvmci-21.2-b08)
• JDK major version: 11
• OS: Windows 10
• Architecture: AMD64

More details

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.

C:\Users\nixin72\repos\shan>native-image -jar .\shan.jar --no-fallback -H:ReflectionConfigurationFiles=reflect-config.json -H:Name=shan --native-image-info --verbose
Executing [
'C:\Program Files\Java\graalvm-ce-java11-21.2.0\bin\java.exe' \
-XX:+UseParallelGC \
-XX:+UnlockExperimentalVMOptions \
-XX:+EnableJVMCI \
-Dtruffle.TrustAllTruffleRuntimeProviders=true \
-Dtruffle.TruffleRuntime=com.oracle.truffle.api.impl.DefaultTruffleRuntime \
-Dgraalvm.ForcePolyglotInvalid=true \
-Dgraalvm.locatorDisabled=true \
-Dsubstratevm.IgnoreGraalVersionCheck=true \
--add-exports=java.base/com.sun.crypto.provider=ALL-UNNAMED \
--add-exports=java.base/jdk.internal.event=ALL-UNNAMED \
--add-exports=java.base/jdk.internal.loader=ALL-UNNAMED \
--add-exports=java.base/jdk.internal.logger=ALL-UNNAMED \
--add-exports=java.base/jdk.internal.misc=ALL-UNNAMED \
--add-exports=java.base/jdk.internal.module=ALL-UNNAMED \
--add-exports=java.base/jdk.internal.org.objectweb.asm=ALL-UNNAMED \
--add-exports=java.base/jdk.internal.org.xml.sax.helpers=ALL-UNNAMED \
--add-exports=java.base/jdk.internal.perf=ALL-UNNAMED \
--add-exports=java.base/jdk.internal.ref=ALL-UNNAMED \
--add-exports=java.base/jdk.internal.util.xml.impl=ALL-UNNAMED \
--add-exports=java.base/jdk.internal.util.xml=ALL-UNNAMED \
--add-exports=java.base/sun.invoke.util=ALL-UNNAMED \
--add-exports=java.base/sun.nio.ch=ALL-UNNAMED \
--add-exports=java.base/sun.reflect.annotation=ALL-UNNAMED \
--add-exports=java.base/sun.reflect.generics.reflectiveObjects=ALL-UNNAMED \
--add-exports=java.base/sun.reflect.generics.repository=ALL-UNNAMED \
--add-exports=java.base/sun.reflect.generics.tree=ALL-UNNAMED \
--add-exports=java.base/sun.security.jca=ALL-UNNAMED \
--add-exports=java.base/sun.security.provider=ALL-UNNAMED \
--add-exports=java.base/sun.security.util=ALL-UNNAMED \
--add-exports=java.base/sun.text.spi=ALL-UNNAMED \
--add-exports=java.base/sun.util.calendar=ALL-UNNAMED \
--add-exports=java.base/sun.util.locale.provider=ALL-UNNAMED \
--add-exports=java.base/sun.util.resources=ALL-UNNAMED \
--add-exports=java.xml.crypto/org.jcp.xml.dsig.internal.dom=ALL-UNNAMED \
--add-exports=jdk.internal.vm.ci/jdk.vm.ci.aarch64=ALL-UNNAMED \
--add-exports=jdk.internal.vm.ci/jdk.vm.ci.amd64=ALL-UNNAMED \
--add-exports=jdk.internal.vm.ci/jdk.vm.ci.code.site=ALL-UNNAMED \
--add-exports=jdk.internal.vm.ci/jdk.vm.ci.code.stack=ALL-UNNAMED \
--add-exports=jdk.internal.vm.ci/jdk.vm.ci.code=ALL-UNNAMED \
--add-exports=jdk.internal.vm.ci/jdk.vm.ci.common=ALL-UNNAMED \
--add-exports=jdk.internal.vm.ci/jdk.vm.ci.hotspot.aarch64=ALL-UNNAMED \
--add-exports=jdk.internal.vm.ci/jdk.vm.ci.hotspot.amd64=ALL-UNNAMED \
--add-exports=jdk.internal.vm.ci/jdk.vm.ci.hotspot.sparc=ALL-UNNAMED \
--add-exports=jdk.internal.vm.ci/jdk.vm.ci.hotspot=ALL-UNNAMED \
--add-exports=jdk.internal.vm.ci/jdk.vm.ci.meta=ALL-UNNAMED \
--add-exports=jdk.internal.vm.ci/jdk.vm.ci.runtime=ALL-UNNAMED \
--add-exports=jdk.internal.vm.ci/jdk.vm.ci.services=ALL-UNNAMED \
--add-exports=jdk.internal.vm.ci/jdk.vm.ci.sparc=ALL-UNNAMED \
--add-exports=jdk.jfr/jdk.jfr.events=ALL-UNNAMED \
--add-exports=jdk.jfr/jdk.jfr.internal.consumer=ALL-UNNAMED \
--add-exports=jdk.jfr/jdk.jfr.internal.handlers=ALL-UNNAMED \
--add-exports=jdk.jfr/jdk.jfr.internal.jfc=ALL-UNNAMED \
--add-exports=jdk.jfr/jdk.jfr.internal=ALL-UNNAMED \
-XX:+UseJVMCINativeLibrary \
-Xss10m \
-Xms1g \
-Xmx13645791232 \
-Duser.country=US \
-Duser.language=en \
-Djava.awt.headless=true \
-Dorg.graalvm.version=21.2.0 \
-Dorg.graalvm.config=CE \
-Dcom.oracle.graalvm.isaot=true \
-Djava.system.class.loader=com.oracle.svm.hosted.NativeImageSystemClassLoader \
-Xshare:off \
--module-path \
'C:\Program Files\Java\graalvm-ce-java11-21.2.0\lib\truffle\truffle-api.jar' \
-Djdk.internal.lambda.disableEagerInitialization=true \
-Djdk.internal.lambda.eagerlyInitialize=false \
-Djava.lang.invoke.InnerClassLambdaMetafactory.initializeLambdas=false \
'-javaagent:C:\Program Files\Java\graalvm-ce-java11-21.2.0\lib\svm\builder\svm.jar' \
-cp \
'C:\Program Files\Java\graalvm-ce-java11-21.2.0\lib\svm\builder\objectfile.jar;C:\Program Files\Java\graalvm-ce-java11-21.2.0\lib\svm\builder\pointsto.jar;C:\Program Files\Java\graalvm-ce-java11-21.2.0\lib\svm\builder\svm.jar' \
'com.oracle.svm.hosted.NativeImageGeneratorRunner$JDK9Plus' \
-imagecp \
'C:\Users\nizin72\repos\shan\shan.jar;C:\Program Files\Java\graalvm-ce-java11-21.2.0\lib\svm\library-support.jar' \
'-H:Path=C:\Users\nixin72\repos\shan' \
'-H:Class@manifest from file:///C:/Users/nixin72/repos/shan/shan.jar=shan.core' \
'-H:Name@manifest from file:///C:/Users/nixin72/repos/shan/shan.jar=shan' \
-H:FallbackThreshold=0 \
-H:ReflectionConfigurationFiles=reflect-config.json \
-H:Name=shan \
-H:+DumpTargetInfo \
'-H:CLibraryPath=C:\Program Files\Java\graalvm-ce-java11-21.2.0\lib\svm\clibraries\windows-amd64'
]
[shan:13500]    classlist:   3,410.53 ms,  0.96 GB
[shan:13500]        setup:     893.99 ms,  0.96 GB
Error: Native-image building on Windows currently only supports target architecture: AMD64 (ARM64 unsupported)
Error: To prevent native-toolchain checking provide command-line option -H:-CheckToolchain
Error: Use -H:+ReportExceptionStackTraces to print stacktrace of underlying exception
[shan:13500]      [total]:   4,354.36 ms,  0.96 GB
# Printing build artifacts to: C:\Users\nixin72\repos\shan\shan.build_artifacts.txt
Error: Image build request failed with exit status 1
com.oracle.svm.driver.NativeImage$NativeImageError: Image build request failed with exit status 1
        at com.oracle.svm.driver.NativeImage.showError(NativeImage.java:1916)
        at com.oracle.svm.driver.NativeImage.build(NativeImage.java:1584)
        at com.oracle.svm.driver.NativeImage.performBuild(NativeImage.java:1545)
        at com.oracle.svm.driver.NativeImage.main(NativeImage.java:1532)

[munishchouhan]

@nixin72 thanks for reporting the issue, we will check it and get back to you

[munishchouhan]

@nixin72 most probably, your machine is not AMD64 as per the error message
I tried it my side and able to build it without any error below are the instructions:

1. mkdir META-INF\native-image
2. java -agentlib:native-image-agent=config-output-dir=META-INF\native-image -jar shan.jar
3. native-image -jar .\shan.jar --no-fallback -H:Name=shan --initialize-at-run-time=shan.core
4. output:

[shan:6960]    classlist:   1,066.31 ms,  0.96 GB
[shan:6960]        (cap):   2,661.04 ms,  0.96 GB
Registering packages for build time initialization: clojure, shan, expound, clj_easy, cli_matic
[shan:6960]        setup:   4,892.67 ms,  0.96 GB
[shan:6960]     (clinit):     269.57 ms,  3.70 GB
[shan:6960]   (typeflow):   3,057.53 ms,  3.70 GB
[shan:6960]    (objects):   8,328.81 ms,  3.70 GB
[shan:6960]   (features):     594.59 ms,  3.70 GB
[shan:6960]     analysis:  13,175.12 ms,  3.70 GB
[shan:6960]     universe:   1,128.47 ms,  4.08 GB
[shan:6960]      (parse):     590.03 ms,  4.08 GB
[shan:6960]     (inline):     873.21 ms,  4.08 GB
[shan:6960]    (compile):  10,733.46 ms,  5.29 GB
[shan:6960]      compile:  13,088.91 ms,  5.29 GB
[shan:6960]        image:   1,734.22 ms,  5.29 GB
[shan:6960]        write:  47,432.87 ms,  5.29 GB
[shan:6960]      [total]:  82,741.10 ms,  5.29 GB
# Printing build artifacts to: C:\Users\mchouhan\Desktop\Issues\github\3860\shan.build_artifacts.txt

[nixin72]

@mcraj017 I have an Intel i7 6500U CPU - I was under the impression that x86_64 and AMD64 were the same thing?

$ lscpu
Architecture:            x86_64
  CPU op-mode(s):        32-bit, 64-bit
  Address sizes:         39 bits physical, 48 bits virtual
  Byte Order:            Little Endian
CPU(s):                  4
  On-line CPU(s) list:   0-3
Vendor ID:               GenuineIntel
  Model name:            Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz
...

I will try exactly the steps you have above however, since the commands are a little different.

Edit: I tried again with exactly what you send above and still no success building. Exact same error message about not supporting the architecture.

[munishchouhan]

@nixin72 I have raised this issue with native-image team

[christianwimmer]

When you then run with -H:-CheckToolchain, do you get a working native image?

Do you have any cross-compilation toolchain installed on your system to produce ARM64 binaries?

[nixin72]

@christianwimmer -

When you then run with -H:-CheckToolchain, do you get a working native image?

running with that flag I get a different error that looks like my toolchain isn't setup properly. However I'm not sure why this is. Compiling a simple C++ project with stdio.h works perfectly fine. I'm not very familiar with Windows however, so I have no idea what I did wrong.

Do you have any cross-compilation toolchain installed on your system to produce ARM64 binaries?

Looking through Visual Studio I don't appear to.

[christianwimmer]

Looks like the cl.exe is really the one from the arm64 directory. So you have your developer prompt set wrongly. https://www.graalvm.org/reference-manual/native-image/#prerequisites has some links to the Microsoft documentation on how to set it.

[nixin72]

Hi, sorry for the late reply

I've set the toolchain properly to be using the x64, but I'm getting the same error - just pointing to the x64 directory instead of the arm64 one.

I'm sure it's just my setup is broken, but I can't figure out what's up. When do

echo %INCLUDE%

I get C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include
Which looks like it should be right, but when I actually open the directory and look at it, I seemingly have everything there except stdio.h?

I tried running a repair installation on Visual Studio but that didn't seem to do anything. I can run C++ files fine from within Visual Studio fine using stdio.h, but trying to do it from the Visual Studio Developer Command Prompt isn't working. No idea what's wrong.

[fniephaus]

Native Image is able to set up Windows build environments automatically for some time now and we finally found and implemented a way to perform the compiler version check that is independent from OS language settings.

I am closing this for now. Please re-open if you are still having problems like this in a dev build or in the upcoming GraalVM for JDK 22 or later.