Error during opening a native lib on Apple M1

Thu Apr 6 19:59:44 UTC 2023

Hi Martin,

I build from the master sources from github the tool. You have to download the llvm from the link on github. The installation via homebrew is not working. 

Cheers,
Clemens

> On 6. Apr 2023, at 16:50, Martin Pernollet <martin.pernollet at protonmail.com> wrote:
> 
> Hi,
> 
> I am also interested in migrating to JDK20 to solve issues on Apple M1.
> 
> I however only found online JExtract 19 [1] (released in July 2022) so I presume it won't generate Java code suitable for FFM at Java20. 
> 
> How did you manage to get jextract generating bindings for Java20?
> 
> Thanks
> 
> [1] https://jdk.java.net/jextract/
> 
> 
> ------- Original Message -------
>> Le jeudi 6 avril 2023 à 16:25, Clemens Lanthaler <clemens.lanthaler at itarchitects.at> a écrit :
>> 
>> 
>> Hi Maurizio,
>> 
>> I just want to say thank you for the delivery of the JDK20
>> implementation. The new API is much better for a Java developer and I am
>> looking forward how it transforms when custom data types are possible in
>> Java.
>> 
>> All my apps are now working on all platforms.
>> 
>> Clemens
>> 
>> 
>>> On 05.09.22 10:40, Maurizio Cimadamore wrote:
>>> 
>>> Hi Clemens,
>>> I believe you have run into a known limitation that Panama (and JNI)
>>> have when it comes to calls spilling arguments on stack on MacOs on M1:
>>> 
>>> https://bugs.openjdk.org/browse/JDK-8275584
>>> 
>>> In most systems, stack arguments are spilled at "slots" that are at
>>> multiple of a certain system size (e.g. 16 bytes).
>>> 
>>> But on MacOs/Aarch64 the stack arguments are "packed" and original
>>> alignment constraints are preserved. The hotspot code does not know,
>>> in JDK 19, how to deal with this scenario.
>>> 
>>> Work is under way to lift this restriction in Java 20:
>>> 
>>> https://github.com/openjdk/panama-foreign/pull/699
>>> 
>>> I believe the difference between 18 and 19 is that in 19 we added some
>>> logic to detect the problematic call shapes (as JNI does), whereas on
>>> 18 the code just led to undefined behavior.
>>> 
>>> It is possible that your application never called this particular
>>> function - if that's the case I'd recommend filtering it out using
>>> jextract filtering options.
>>> 
>>> Maurizio
>>> 
>>>> On 04/09/2022 18:13, Clemens Lanthaler wrote:
>>> 
>>>> Hello everyone,
>>>> 
>>>> I have just ported over LibrawFX to JDK19 and have used the latest
>>>> bin release of jextract on OSX/win for porting it over to the JDK19
>>>> lang features. The code is working under JDK18 (1.8.0 release branch).
>>>> 
>>>> When I execute the new code under an Apple M1 I am getting always on
>>>> the init method / first call to the native lib the error message:
>>>> java.lang.ExceptionInInitializerError: Exception
>>>> java.lang.UnsupportedOperationException: Call type not supported on
>>>> this platform [in thread "Thread-6"]
>>>>     at
>>>> java.base/jdk.internal.foreign.abi.aarch64.CallArranger$StorageCalculator.stackAlloc(CallArranger.java:206)
>>>>     at
>>>> java.base/jdk.internal.foreign.abi.aarch64.CallArranger$StorageCalculator.stackAlloc(CallArranger.java:217)
>>>>     at
>>>> java.base/jdk.internal.foreign.abi.aarch64.CallArranger$StorageCalculator.nextStorage(CallArranger.java:244)
>>>>     at
>>>> java.base/jdk.internal.foreign.abi.aarch64.CallArranger$UnboxBindingCalculator.getBindings(CallArranger.java:395)
>>>>     at
>>>> java.base/jdk.internal.foreign.abi.aarch64.CallArranger.getBindings(CallArranger.java:146)
>>>>     at
>>>> java.base/jdk.internal.foreign.abi.aarch64.CallArranger.arrangeDowncall(CallArranger.java:153)
>>>>     at
>>>> java.base/jdk.internal.foreign.abi.aarch64.macos.MacOsAArch64Linker.arrangeDowncall(MacOsAArch64Linker.java:56)
>>>>     at
>>>> java.base/jdk.internal.foreign.abi.AbstractLinker.lambda$downcallHandle$0(AbstractLinker.java:52)
>>>>     at
>>>> java.base/jdk.internal.foreign.abi.SoftReferenceCache$Node.get(SoftReferenceCache.java:52)
>>>>     at
>>>> java.base/jdk.internal.foreign.abi.SoftReferenceCache.get(SoftReferenceCache.java:38)
>>>>     at
>>>> java.base/jdk.internal.foreign.abi.AbstractLinker.downcallHandle(AbstractLinker.java:50)
>>>>     at
>>>> java.base/java.lang.foreign.Linker.downcallHandle(Linker.java:221)
>>>>     at
>>>> org.librawfx at 1.8.1-SNAPSHOT/org.libraw.linuxosx.RuntimeHelper.lambda$downcallHandle$5(RuntimeHelper.java:60)
>>>>     at java.base/java.util.Optional.map(Optional.java:260)
>>>>     at
>>>> org.librawfx at 1.8.1-SNAPSHOT/org.libraw.linuxosx.RuntimeHelper.downcallHandle(RuntimeHelper.java:60)
>>>>     at
>>>> org.librawfx at 1.8.1-SNAPSHOT/org.libraw.linuxosx.constants$3.<clinit>(constants$3.java:52)
>>>> 
>>>> The code is on Github under https://github.com/lanthale/librawfx. The
>>>> JDK19 stuff is checked into the master branch. Just clone it and run
>>>> it via maven.
>>>> 
>>>> The same I have done for LibheifFX and all is working. There must be
>>>> some difference how Libraw is handling all the stuff. Therefore I
>>>> would appreciate if you can help me.
>>>> 
>>>> best regards,
>>>> Clemens
>> 
>> 
>> --
>> ITArchitects
>> CEO: B.Sc. Clemens Lanthaler
>> Forchachstrasse 3
>> A-6166 Fulpmes
>> Tel.: +43 (0)650 855 2954
>> email: office at itarchitects.at
>> homepage: http://www.itarchitects.at
>> -------------------------------------------------
>> Notice: This e-mail and any attachments are confidential and may be privileged.
>> If you are not the intended recipient, notify the sender immediately, destroy all
>> copies from your system and do not disclose or use the information for any purpose.
>> Diese E-Mail inklusive aller Anhaenge ist vertraulich und koennte bevorrechtigtem
>> Schutz unterliegen. Wenn Sie nicht der beabsichtigte Adressat sind, informieren Sie
>> bitte den Absender unverzueglich, loeschen Sie alle Kopien von Ihrem System und
>> veroeffentlichen Sie oder nutzen Sie die Information keinesfalls, gleich zu welchem Zweck.