Error during opening a native lib on Apple M1

Fri Apr 7 05:32:11 UTC 2023

Or you can use the llvm bundled with Xcode. But yes, the homebrew version doesn’t work here.

Also note, that you need two different JDKs: JDK20 obviously, which you pass to the build as an argument and an older JDK (I used 17) to run the outdated gradle/gradlew, which isn't compatible with 20 yet.

> 
> Am 06.04.2023 um 22:00 schrieb clemens.lanthaler at itarchitects.at:
> 
> 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.
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2491 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20230407/e6818972/smime-0001.p7s>