native-maven-plugin >= v0.9.26: Build fails due to graal_isolate.h not being put into target folder

[milarine]

Describe the problem

After upgrading native-maven-plugin to version 0.9.26 our build fails, because the files graal_isolate.h and graal_isolate_dynamic.h are being put on root level instead of the target folder as it was in version 0.9.25. We also tested higher versions including the latest 10.0.2 and the behaviour is the same.

With versions <0.9.26 the output looks as follows:

Produced artifacts:
/target/graal_isolate.h (header)
/target/graal_isolate_dynamic.h (header)
/target/libMyLibGraalVM.build_artifacts.txt (txt)
/target/libMyLibGraalVM.h (header)
/target/libMyLibGaalVM.so (shared_lib)
/target/libMyLibGraalVM_dynamic.h (header)

With versions >=0.9.26:

Produced artifacts:
/graal_isolate.h (header)
/graal_isolate_dynamic.h (header)
/target/libMyLibGraalVM.build_artifacts.txt (txt)
/target/libMyLibGraalVM.h (header)
/target/libMyLibGaalVM.so (shared_lib)
/target/libMyLibGraalVM_dynamic.h (header)

This is our plugin configuration:

<plugin>
    <groupId>org.graalvm.buildtools</groupId>
    <artifactId>native-maven-plugin</artifactId>
    <version>${native-maven-plugin.version}</version>
    <extensions>true</extensions>
    <executions>
        <execution>
            <id>build-native</id>
            <goals>
                <goal>compile-no-fork</goal>
            </goals>
            <phase>compile</phase>
        </execution>
    </executions>
    <configuration>
        <sharedLibrary>true</sharedLibrary>
        <imageName>libMyLibGraalVM</imageName>
        <buildArgs>
            <arg>-Dbasepath=${project.basedir}</arg>
            <arg>-H:IncludeResources=truststore.jks</arg>
            <arg>-H:ReflectionConfigurationFiles=src/main/resources/reflection-config.json</arg>
            <buildArg>-O3</buildArg>
        </buildArgs>
    </configuration>
</plugin>

Is this a bug or do we have to configure something additionally?

System Info:

• OS: Debian 11 (bullseye)
• GraalVM Version: graalvm-ce-java17-22.2.0
• Java Version: 17
• Plugin version: native-maven-plugin:0.9.26

[vjovanov]

Thanks for reporting @milarine!

A verbose output of the native image command invocation would be useful to see what is happening. Would it be possible to get a reproducer?

[milarine]

Hello @vjovanov, thanks for your reply! You can find a reproducer here: https://github.com/milarine/test-native-build-tools

[vjovanov]

I used GraalVM 21, and had to modify the function signature to:

public static int main(IsolateThread isolateThread) {

as String is not a valid return type for native code. Then I added the dependency to GraalVM SDK:

<groupId>org.graalvm.sdk</groupId>
<artifactId>graal-sdk</artifactId>
<version>21.0.0</version>

and <buildArg>-H:+AllowDeprecatedBuilderClassesOnImageClasspath</buildArg>.

The output is as expected with build tools 10.2 and with 0.9.25.

/home/vjovanov/c/public/test-native-build-tools/target/graal_isolate.h (c_header)
 /home/vjovanov/c/public/test-native-build-tools/target/graal_isolate_dynamic.h (c_header)
 /home/vjovanov/c/public/test-native-build-tools/target/libTestNativeBuildTools.h (c_header)
 /home/vjovanov/c/public/test-native-build-tools/target/libTestNativeBuildTools.so (shared_library)
 /home/vjovanov/c/public/test-native-build-tools/target/libTestNativeBuildTools_dynamic.h (c_header)

Please confirm if this also happens on your machine.

[milarine]

Can you maybe send a link to the GraalVM version you were using? We are a bit confused about the change in version numbering. We tested your supposed changes with this version: https://github.com/graalvm/graalvm-ce-builds/releases/tag/vm-21.3.3.1 and get the following error when running mvn package:

[INFO] Executing: /home/XXX/graalvm-ce-java17-21.3.3.1/bin/native-image -cp /mnt/c/Users/XXX/repos/test-native-build-tools/target/classes:/home/XXX/.m2/repository/org/graalvm/sdk/graal-sdk/21.0.0/graal-sdk-21.0.0.jar --no-fallback --shared -o /mnt/c/Users/XXX/repos/test-native-build-tools/target/libTestNativeBuildTools -Dbasepath=/mnt/c/Users/XXX/repos/test-native-build-tools -H:+AllowDeprecatedBuilderClassesOnImageClasspath -O3
Error: Unrecognized option: -o
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  8.984 s
[INFO] Finished at: 2024-06-18T10:10:14+02:00
[INFO] ------------------------------------------------------------------------
[WARNING] The requested profile "native" could not be activated because it does not exist.
[ERROR] Failed to execute goal org.graalvm.buildtools:native-maven-plugin:0.10.2:compile-no-fork (build-native) on project test-native-build-tools: Execution of /home/XXX/graalvm-ce-java17-21.3.3.1/bin/native-image -cp /mnt/c/Users/XXX/repos/test-native-build-tools/target/classes:/home/XXX/.m2/repository/org/graalvm/sdk/graal-sdk/21.0.0/graal-sdk-21.0.0.jar --no-fallback --shared -o /mnt/c/Users/XXX/repos/test-native-build-tools/target/libTestNativeBuildTools -Dbasepath=/mnt/c/Users/XXX/repos/test-native-build-tools -H:+AllowDeprecatedBuilderClassesOnImageClasspath -O3 returned non-zero result -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException

We also built a Docker image for reproducing our problem to make sure it has nothing to do with our local environment, which we can provide to you if you are interested. Thanks a lot! :)

[vjovanov]

I used the version GraalVM for JDK 21 (or 23.1.x according to the old versioning scheme). Could you please try that to see if it works for you?

[milarine]

Upgrading GraalVM to JDK 21 works as you suggested. Though the issue still remains in the version for Java 17, which is not relevant for us anymore but might be for other people who cannot update easily.

[vjovanov]

Thanks for the report, this ticket can serve as reference for all people that hit this issue on JDK 17.