Platform.RESOURCE_PREFIX on Darwin x64 and M1 #1313
Comments
|
Yes there is. Darwin is a special case in the JNA codebase. Darwin uses libraries, that support multiple architectures in a single library. Apple has a strange way to support this, but IMHO that is one of the the few very nice things mac OS has to offer. Have a look at the libjnidispatch.jnilib file in the jna.jar. It contains the dispatch library for amd64 and aarch64. In the past darwin binaries contained ppc and x86 code, or x86 and x64. The tool you are looking for is lipo - as a final hint, the main build script of JNA holds the necessary commands to merge the native libraries. |
|
Thanks for your support and the hints, gonna look into it! |
|
I decided to see if we can unify the behavior of darwin and the rest of the world. My intention is this:
|
|
One other thing to consider is the JVM in use. If using an x86/x64 JVM on M1 hardware, Rosetta will indicate a virtual processor to match, for compatibility. You need to be running on aarch64 JVM to get |
|
@dbwiddis from my POV this is the correct assumption and the same on x86. If you run a 32 bit VM, you will get 32 bit libraries, if you run a 64bit JVM you get 64bit ones. It is the same here. |
…h and support darwin as fallback The darwin platform traditionally used fatbinaries to support multiple architectures. This works, but is a problem: a) when apple decides, that only certain architectures may be bundled (it was reported, that the presence of x86 caused appstore validation to fail) b) when upstream does not bundle the artifacts, but builds them in isolation. Given, that JNA also hit (b) and needed post processing to merge binaries, moving darwin to the same scheme as other OSes (<os>-<arch>) is considered sensible. While the resource prefix is changed, the old "darwin" prefix is still considered for extraction and thus old libraries will continue to work.
…h and support darwin as fallback The darwin platform traditionally used fatbinaries to support multiple architectures. This works, but is a problem: a) when apple decides, that only certain architectures may be bundled (it was reported, that the presence of x86 caused appstore validation to fail) b) when upstream does not bundle the artifacts, but builds them in isolation. Given, that JNA also hit (b) and needed post processing to merge binaries, moving darwin to the same scheme as other OSes (<os>-<arch>) is considered sensible. While the resource prefix is changed, the old "darwin" prefix is still considered for extraction and thus old libraries will continue to work.
|
@matthiasblaesing @phxql I am running: |
|
I switched to MSFT JDK 16 for Arm and finally I could see something like this 👍🏼 @matthiasblaesing @phxql This may be helpful! |
|
Thank you - this test shows, that JNA in principle works and it shows, that the profix is switched, what it does ntot show is, whether or not the library actually can be loaded. I did a test with the changed prefix and the current x86-64 build of the argon library and it worked (#1316 (comment)). If you can provide a build of the darwin aarch64 variant of the argon2 library, the sample can be trivially adjusted. |
|
I just built a small commandline tool to run the Argon2 libraries with JNA. We will test that on M1 and x64 (Rosetta and native) and report back. Thanks for your support! https://github.com/phxql/argon2-jvm/tree/test/jna-pr-1316/argon2-jvm-runner |
…h and support darwin as fallback The darwin platform traditionally used fatbinaries to support multiple architectures. This works, but is a problem: a) when apple decides, that only certain architectures may be bundled (it was reported, that the presence of x86 caused appstore validation to fail) b) when upstream does not bundle the artifacts, but builds them in isolation. Given, that JNA also hit (b) and needed post processing to merge binaries, moving darwin to the same scheme as other OSes (<os>-<arch>) is considered sensible. While the resource prefix is changed, the old "darwin" prefix is still considered for extraction and thus old libraries will continue to work.
…h and support darwin as fallback The darwin platform traditionally used fatbinaries to support multiple architectures. This works, but is a problem: a) when apple decides, that only certain architectures may be bundled (it was reported, that the presence of x86 caused appstore validation to fail) b) when upstream does not bundle the artifacts, but builds them in isolation. Given, that JNA also hit (b) and needed post processing to merge binaries, moving darwin to the same scheme as other OSes (<os>-<arch>) is considered sensible. While the resource prefix is changed, the old "darwin" prefix is still considered for extraction and thus old libraries will continue to work.
[GH-1313] Move default darwin prefix to darwin-$arch and support darwin as fallback
|
Prefix change was merged to master, we need to see when a new release is cut. |
|
Thanks a lot for your work :) |
5.7.0OpenJDK 11OSXx64andM1 aarch64Hello! I maintain argon2-jvm, which includes a compiled argon2 library in the JAR for different operating systems (windows x86 & x64, linux x86, x64, arm, aarch64, etc.).
I now want to support both x64 macs and M1 macs. But there's a problem:
Platform.RESOURCE_PREFIXreturnsdarwinon both x64 and M1 architecture. It doesn't include the architecture, and it prevents me from supporting both the M1 and x64 macs at the same time when using the "extract library from classpath feature".I expected the resource prefix to be something like
darwin-aarch64. The argon2 lib for OSX x64 is stored indarwinsubfolder, i can't put the M1 version in the same folder, as it would overwrite the x64 one.See phxql/argon2-jvm#78
Is there any workaround for this?
Thanks a lot!
The text was updated successfully, but these errors were encountered: