Investigate removal of CAP Cache files

[jperedadnr]

[jperedadnr]

Removing the CAP options "-H:+UseCAPCache", "-H:CAPCacheDir=", and using "-H:-UseCAPCache" (somehow this is required, though by default it should be already false), I get to avoid the CAP cache, which is the C Annotation Processor Cache), I get:

Error: Darwin native toolchain (x86_64) implies native-image target architecture class jdk.vm.ci.amd64.AMD64 but configured native-image target architecture is class jdk.vm.ci.aarch64.AArch64.
[Thu Feb 03 20:48:26 CET 2022][INFO] [SUB] Error: To prevent native-toolchain checking provide command-line option -H:-CheckToolchain

After adding "-H:-CheckToolchain" I see native image creates under gvm/tmp/SVM-XXX the usual c files like AArch64LibCHelperDirectives.c, AMD64LibCHelperDirectives.c, PosixDirectives.c:

int PosixDirectives() {
    printf("NativeCodeInfo:PosixDirectives:ConstantInfo:CTL_HW:PropertyInfo:size=%lu\n", ((unsigned long)sizeof(CTL_HW)));
...

and then it starts compiling them. All seem to compile fine, but PosixDirectives fails with several errors like:

Error compiling query code (in target/gluonfx/arm64-ios/gvm/tmp/SVM-1643917828452/PosixDirectives.c). 
Compiler command '/usr/bin/cc -Wall -Werror -Wno-tautological-compare -ObjC -o target/gluonfx/arm64-ios/gvm/tmp/SVM-1643917828452/PosixDirectives target/gluonfx/arm64-ios/gvm/tmp/SVM-1643917828452/PosixDirectives.c' output included error: 
target/gluonfx/arm64-ios/gvm/tmp/SVM-1643917828452/PosixDirectives.c:406:198: error: no member named '__fp' in 'struct __darwin_x86_thread_state64'; did you mean '__fs'?

where line 406:

printf("NativeCodeInfo:PosixDirectives:StructInfo:struct___darwin_mcontext64:StructFieldInfo:__ss___fp:PropertyInfo:size=%lu\n", ((unsigned long)sizeof(((struct __darwin_mcontext64 *) 0)->__ss.__fp)));

(all errors are just related to this struct___darwin_mcontext64).

Looks like to build a native image for iOS we use a Mac, so compilation is picking x86_64 and not aarch64.

However, when we build the CAP cache for iOS on Mac, we simply do:

$GRAALVM_HOME/bin/native-image -H:CAPCacheDir=/tmp/cap -H:+ExitAfterCAPCache -H:+NewCAPCache  -cp target/classes hello.HelloWorld

so I wonder how that works.

Commenting out the Platform.IOS_AARCH64 from AArch64DarwinUContextRegisterDumperFeature and from Signal and removing the guard in SubstrateSegfaultHandlerFeature:

- VMError.guarantee(ImageSingletons.contains(RegisterDumper.class));

and with the changes in Substrate (to disable CAP cache and toolchain check), build and deploy work.

On Android clang is needed:

export PATH=$PATH:$ANDROID_NDK/toolchains/llvm/prebuilt/linux-x86_64/bin/

[SaptarshiSarkar12]

@jperedadnr I was trying out GitHub Actions' M1 runner (macos-14) by building a native executable for a JavaFx application using Gluonfx Maven plugin. But, I encountered an error (similar to the above one, I guess :smiley:) as given below :point_down:

[Tue Mar 05 10:42:08 UTC 2024][INFO] [SUB] Error: Path to C Annotation Processor Cache must be specified using -H:CAPCacheDir= when the option -H:+UseCAPCache or -H:+NewCAPCache is used.
[Tue Mar 05 10:42:08 UTC 2024][INFO] [SUB] com.oracle.svm.core.util.UserError$UserException: Path to C Annotation Processor Cache must be specified using -H:CAPCacheDir= when the option -H:+UseCAPCache or -H:+NewCAPCache is used.
[Tue Mar 05 10:42:08 UTC 2024][INFO] [SUB] 	at org.graalvm.nativeimage.builder/com.oracle.svm.core.util.UserError.abort(UserError.java:73)
[Tue Mar 05 10:42:08 UTC 2024][INFO] [SUB] 	at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.c.CAnnotationProcessorCache.<init>
....(truncated)....

You can check the full log here - https://github.com/SaptarshiSarkar12/Drifty/actions/runs/8154918145/job/22289325074#step:8:3551 Also, the respective plugin configuration can be found here - https://github.com/SaptarshiSarkar12/Drifty/blob/468a97b761495b2677d6bbfcadd9fd1e3a970c3d/GUI/pom.xml#L45 I would be glad if you can kindly tell me how to fix this issue. I have checked that it is not a graalvm issue rather a problem with the plugin, I suppose :smile:.