Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add darwin-aarch64 support #1297

Merged
merged 6 commits into from
Jan 27, 2021

Conversation

tresf
Copy link
Contributor

@tresf tresf commented Jan 15, 2021

This is a rework of #1238 which removes the multi-arch Makefile looping currently used on macOS and adapts it to only build a single, specified architecture, and lipo it back onto the native library.

TODO:

  • Build atop the win32-aarch PR
  • Chery-pick @fkistner's Big Sur tests fix
  • Cherry-pick @fkistner's VarArgs tests fix
  • Add aarch64 target (most work authored by @Vzor-)
  • Update macOS documentation
  • Update changelog with accreditation
  • Fix failing unit tests

Description:

Previously, the native/Makefile blindly looped through supported architectures. Now, each arch is supplied manually, to mimic other environments. This has the advantage of a deterministic build, but to two slight disadvantages (1) Requires a second call to ant (2) , ${os.prefix} now diverges from the resource path inside the jar, requiring a new ${resource.prefix} variable.

A “fat” multi-arch library is still the resulting object.

Furthemore, in testing PPC builds, it appears there was some opportunity for cleanup, so some lines changed are as a result of that.

The bulk of the code changes are in 891c2b4 (or if it's been squashed out, the commit titled Add darwin-aarch64 to build).

@tresf
Copy link
Contributor Author

tresf commented Jan 15, 2021

Current state of the unit tests:

  • com.sun.jna: 1 failure
  • com.sun.jna.different_package: 1 failure
Click to show details

image

test:
    [mkdir] Created dir: /Users/owner/jna/build/junit-results/darwin-aarch64
     [echo] Saving test results in /Users/owner/jna/build/junit-results/darwin-aarch64
    [junit] Testsuite: com.sun.jna.AnnotatedLibraryTest
    [junit] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.055 sec
    [junit] 
    [junit] Testsuite: com.sun.jna.ArgumentsMarshalNullableTest
    [junit] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.404 sec
    [junit] 
    [junit] Testsuite: com.sun.jna.ArgumentsMarshalTest
    [junit] Tests run: 41, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.438 sec
    [junit] 
    [junit] Testsuite: com.sun.jna.ArgumentsWrappersMarshalTest
    [junit] Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.439 sec
    [junit] 
    [junit] Testsuite: com.sun.jna.BufferArgumentsMarshalTest
    [junit] Tests run: 14, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.385 sec
    [junit] 
    [junit] Testsuite: com.sun.jna.ByReferenceArgumentsTest
    [junit] Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.402 sec
    [junit] 
    [junit] Testsuite: com.sun.jna.ByReferenceToStringTest
    [junit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.341 sec
    [junit] 
    [junit] Testsuite: com.sun.jna.CallbacksTest
    [junit] JNA: Can't attach native thread to VM for callback: -1 (check stacksize for callbacks)
    [junit] Tests run: 53, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 9.737 sec
    [junit] 
    [junit] ------------- Standard Error -----------------
    [junit] Warning: JVM did not GC Thread mapping after native thread terminated
    [junit] ------------- ---------------- ---------------
    [junit] Testsuite: com.sun.jna.DefaultMethodInvocationTest
    [junit] Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.401 sec
    [junit] 
    [junit] Testsuite: com.sun.jna.DirectArgumentsMarshalNullableTest
    [junit] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.41 sec
    [junit] 
    [junit] Testsuite: com.sun.jna.DirectArgumentsMarshalTest
    [junit] Tests run: 41, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.433 sec
    [junit] 
    [junit] Testsuite: com.sun.jna.DirectArgumentsWrappersMarshalTest
    [junit] Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.392 sec
    [junit] 
    [junit] Testsuite: com.sun.jna.DirectBufferArgumentsMarshalTest
    [junit] Tests run: 14, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.406 sec
    [junit] 
    [junit] Testsuite: com.sun.jna.DirectByReferenceArgumentsTest
    [junit] Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.385 sec
    [junit] 
    [junit] Testsuite: com.sun.jna.DirectCallbacksTest
    [junit] #
    [junit] # A fatal error has been detected by the Java Runtime Environment:
    [junit] #
    [junit] #  SIGSEGV (0xb) at pc=0x0000000105368128, pid=90184, tid=5891
    [junit] #
    [junit] # JRE version: OpenJDK Runtime Environment (11.0.10+9) (build 11.0.10+9-ea)
    [junit] # Java VM: OpenJDK 64-Bit Server VM (11.0.10+9-ea, mixed mode, tiered, compressed oops, g1 gc, bsd-aarch64)
    [junit] # Problematic frame:
    [junit] # V  [libjvm.dylib+0x368128]  jni_CallObjectMethod+0x108
    [junit] #
    [junit] # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
    [junit] #
    [junit] # An error report file with more information is saved as:
    [junit] # /Users/owner/jna/hs_err_pid90184.log
    [junit] #
    [junit] # If you would like to submit a bug report, please visit:
    [junit] #   https://bugreport.java.com/bugreport/crash.jsp
    [junit] #
    [junit] Testsuite: com.sun.jna.DirectCallbacksTest
    [junit] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0 sec
    [junit] 
    [junit] Testcase: com.sun.jna.DirectCallbacksTest:testUnionByValueCallbackArgument:	Caused an ERROR
    [junit] Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit.
    [junit] junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit.
    [junit] 	at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
    [junit] 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    [junit] 
    [junit] 
    [junit] Test com.sun.jna.DirectCallbacksTest FAILED (crashed)
    [junit] Testsuite: com.sun.jna.DirectReturnTypesTest
    [junit] Tests run: 19, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.42 sec
    [junit] 
    [junit] Testsuite: com.sun.jna.DirectStructureByValueTest
    [junit] Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.376 sec
    [junit] 
    [junit] Testsuite: com.sun.jna.DirectTest
    [junit] Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.39 sec
    [junit] 
    [junit] Testsuite: com.sun.jna.DirectTypeMapperTest
    [junit] Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.382 sec
    [junit] 
    [junit] Testsuite: com.sun.jna.ELFAnalyserTest
    [junit] Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.065 sec
    [junit] 
    [junit] Testsuite: com.sun.jna.FunctionTest
    [junit] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.392 sec
    [junit] 
    [junit] Testsuite: com.sun.jna.HeadlessLoadLibraryTest
    [junit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.357 sec
    [junit] 
    [junit] Testsuite: com.sun.jna.IntegerTypeTest
    [junit] Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.342 sec
    [junit] 
    [junit] Testsuite: com.sun.jna.JNALoadTest
    [junit] Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.744 sec
    [junit] 
    [junit] Testsuite: com.sun.jna.LastErrorTest
    [junit] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.409 sec
    [junit] 
    [junit] Testsuite: com.sun.jna.LibraryLoadTest
    [junit] Tests run: 23, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.202 sec
    [junit] 
    [junit] Testsuite: com.sun.jna.MemoryTest
    [junit] Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 11.399 sec
    [junit] 
    [junit] Testsuite: com.sun.jna.NativeLibraryTest
    [junit] Tests run: 22, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.435 sec
    [junit] 
    [junit] Testsuite: com.sun.jna.NativeTest
    [junit] Tests run: 33, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.463 sec
    [junit] 
    [junit] ------------- Standard Error -----------------
    [junit] Jan 14, 2021 10:08:42 PM com.sun.jna.Native getCharset
    [junit] WARNING: JNA Warning: Encoding 'unsupported' is unsupported (unsupported)
    [junit] Jan 14, 2021 10:08:42 PM com.sun.jna.Native getCharset
    [junit] WARNING: JNA Warning: Using fallback encoding UTF-8
    [junit] ------------- ---------------- ---------------
    [junit] Testsuite: com.sun.jna.NativedMappedTest
    [junit] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.371 sec
    [junit] 
    [junit] Testsuite: com.sun.jna.PerformanceTest
    [junit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.054 sec
    [junit] 
    [junit] Testsuite: com.sun.jna.PlatformTest
    [junit] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.063 sec
    [junit] 
    [junit] Testsuite: com.sun.jna.PointerBufferTest
    [junit] Tests run: 16, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.344 sec
    [junit] 
    [junit] Testsuite: com.sun.jna.PointerTest
    [junit] Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.342 sec
    [junit] 
    [junit] Testsuite: com.sun.jna.PrematureGCTest
    [junit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.348 sec
    [junit] 
    [junit] Testsuite: com.sun.jna.ReturnTypesTest
    [junit] Tests run: 19, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.397 sec
    [junit] 
    [junit] Testsuite: com.sun.jna.StructureBufferFieldTest
    [junit] Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.341 sec
    [junit] 
    [junit] Testsuite: com.sun.jna.StructureByValueTest
    [junit] Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.369 sec
    [junit] 
    [junit] Testsuite: com.sun.jna.StructureFieldOrderInspectorTest
    [junit] Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.519 sec
    [junit] 
    [junit] Testsuite: com.sun.jna.StructureTest
    [junit] Tests run: 90, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.464 sec
    [junit] 
    [junit] Testsuite: com.sun.jna.TypeMapperTest
    [junit] Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.402 sec
    [junit] 
    [junit] Testsuite: com.sun.jna.UnionTest
    [junit] Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.395 sec
    [junit] 
    [junit] Testsuite: com.sun.jna.VMCrashProtectionTest
    [junit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.316 sec
    [junit] 
    [junit] Testsuite: com.sun.jna.VarArgsCheckerTest
    [junit] Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.055 sec
    [junit] 
    [junit] Testsuite: com.sun.jna.VarArgsTest
    [junit] Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.387 sec
    [junit] 
    [junit] Testsuite: com.sun.jna.different_package.PrivateDirectCallbacksTest
    [junit] #
    [junit] # A fatal error has been detected by the Java Runtime Environment:
    [junit] #
    [junit] #  SIGSEGV (0xb) at pc=0x0000000106b6ada8, pid=90247, tid=6403
    [junit] #
    [junit] # JRE version: OpenJDK Runtime Environment (11.0.10+9) (build 11.0.10+9-ea)
    [junit] # Java VM: OpenJDK 64-Bit Server VM (11.0.10+9-ea, mixed mode, tiered, compressed oops, g1 gc, bsd-aarch64)
    [junit] # Problematic frame:
    [junit] # V  [libjvm.dylib+0x36ada8]  jni_CallVoidMethod+0x110
    [junit] #
    [junit] # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
    [junit] #
    [junit] # An error report file with more information is saved as:
    [junit] # /Users/owner/jna/hs_err_pid90247.log
    [junit] #
    [junit] # If you would like to submit a bug report, please visit:
    [junit] #   https://bugreport.java.com/bugreport/crash.jsp
    [junit] #
    [junit] Testsuite: com.sun.jna.different_package.PrivateDirectCallbacksTest
    [junit] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0 sec
    [junit] 
    [junit] Testcase: com.sun.jna.different_package.PrivateDirectCallbacksTest:testCallVoidCallback:	Caused an ERROR
    [junit] Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit.
    [junit] junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit.
    [junit] 	at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
    [junit] 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    [junit] 
    [junit] 
    [junit] Test com.sun.jna.different_package.PrivateDirectCallbacksTest FAILED (crashed)
    [junit] Testsuite: com.sun.jna.different_package.PrivateLibraryInfoTest
    [junit] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.335 sec
    [junit] 
[junitreport] Processing /Users/owner/jna/build/junit-results/darwin-aarch64/TESTS-TestSuites.xml to /var/folders/mp/xz8fb9m55f9g8vb7fs9gc3140000gn/T/null341162982
[junitreport] Loading stylesheet jar:file:/opt/homebrew/Cellar/ant/1.10.9/libexec/lib/ant-junit.jar!/org/apache/tools/ant/taskdefs/optional/junit/xsl/junit-frames.xsl
[junitreport] Transform time: 391ms
[junitreport] Deleting: /var/folders/mp/xz8fb9m55f9g8vb7fs9gc3140000gn/T/null341162982
     [echo] View test report in file:///Users/owner/jna/build/reports/junit/darwin-aarch64/index.html

@matthiasblaesing
Copy link
Member

@tresf were you able to rebuild the x86 (32bit) library with this? I was able to build x86-64 against an older SDK (is this needed or are mac OS builds backwards compatible?) and I was able to build aarch64 against the 12.X SDK.

My understanding is, that Xcode 9 is needed to build x86, but that does not run on mac OS catalina. Do you have an advise what could be tested?

My old build pipeline used travis-ci to build the mac OS libraries, but that also fails now (brew somehow changed and tries to compile JDK 15 on an old mac and times out). Maybe it is time to drop x86 for mac OS?

@dbwiddis
Copy link
Contributor

dbwiddis commented Jan 25, 2021

Maybe it is time to drop x86 for mac OS?

I think this is an entirely reasonable decision. Apple officially stopped supporting 32-bit with macOS 10.15 (Catalina). OS warnings were given beginning in 10.13.4 (a High Sierra update) and throughout 10.14 (Mojave). Mac users who sill want to use 32-bit applications know they need to use an older version of the OS (and presumably an application depending on an older version of JNA as well).

I, along with millions of other Mac users, have long since found replacements for 32-bit apps we loved.

@fkistner
Copy link
Contributor

fkistner commented Jan 25, 2021

FWIW, while unsupported it is still possible to compile 32bit binaries even on the latest macOS Big Sur using the MacOSX SDK and compiler from Xcode 9.4.1 (just unpacking and applying a few tweaks to the Makefile is sufficient):

ant -DSDKROOT=/Applications/Xcode_9.4.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk

That being said, I agree that dropping 32bit support seems very reasonable.

@fkistner
Copy link
Contributor

is this needed or are mac OS builds backwards compatible?

Apple SDKs are backwards compatible to a certain degree, e.g. the SDK that ships with Xcode 9.4.1 has a minimum deployment target of 10.4. To ensure the resulting library is actually backwards compatible, the deployment has to be set correctly and no new APIs may be referenced.

There is a compiler warning that will flag usages of APIs that are not available for the given deployment target: -mmacosx-version-min=10.4 -Wpartial-availability
Unfortunately, the way we are currently configuring libffi seems to enable mkostemp. So it appears JNA will only work on macOS 10.12+, when built on a recent machine.

jna/native/libffi/src/closures.c:568:8: warning: 'mkostemp' is only available on macOS 10.12 or newer [-Wunguarded-availability]
   fd = mkostemp (name, flags);
        ^~~~~~~~

@tresf
Copy link
Contributor Author

tresf commented Jan 25, 2021

I would agree with the proposition of removing 32-bit binaries moving forward. Note, this doesn't actually remove 32-bit support from JNA, just stops shipping with it. The build environment was intentionally tested against the following configurations: PPC32, PPC64, x86, x86_64, ARM64.

Do you have an advise what could be tested?

If the team would like 32-bit tested, it would require a 32-bit JVM, which seems hard to come by. Looking at the Oracle Java 8 downloads, I can't find a build of Java 8 with 32-bit support for Apple, and they date back about 7 years.

Similarly, Java 7's first release from Oracle for Mac only targeted 64-bit JVM, which was released 9 years ago.

I think it's safe to say that testing a 32-bit binary will requiring going all the way back to Apple's Java 6 on a 32-bit machine or VM. If you'd like this tested prior to merging let me know, although @fkistner's findings about libffi suggest that there may be some incompatibilities with the temporary file handling (mkostemp) which -- even if resolved -- may result in more upstream libffi patches.

@matthiasblaesing
Copy link
Member

@tresf @fkistner thank you both for working on mac os aarch64. I had a look at both PRs and I like the build approach taken here better. Reason is, that from my POV it simplifies the build logic. I.e. no black magic in the Makefile to build multiple architectures, just a single build.

Things that need considering/doing:

  • the two commits @fkistner authored, that enable building with older SDKs should be applied onto this: c783a4d b802350
  • consider the cherry pick done in 752d784
  • drop the x86 build from the native libraries - there is no real option to test them and if the JNI defines of the build JDK do not match the target JDK the build is invalid. This works for cross compiling aarch64 on amd64 for windows and mac os, as the JNI defines are identical

After that is done, I should be able to rebuild the x86-64 binary with Xcode 9, the aarch64 binary with Xcode 12, and run unittests on x86-64. This will be merged and we can plan a release.

@tresf
Copy link
Contributor Author

tresf commented Jan 26, 2021

the two commits @fkistner authored, that enable building with older SDKs should be applied onto this: c783a4d b802350

From what I can tell, b802350 only applies to the "black-magic" ALT_ARCHS+= logic. I do no think it belongs in this PR. c783a4d should be doable, but due to code differences will probably lose accreditation. I'm not entirely sure what the difference is between before and after, but I'm happy to add it in.

consider the cherry pick done in 752d784

My mistake. @fkistner had answered my question over on 8b9e010 but I missed it.

@tresf
Copy link
Contributor Author

tresf commented Jan 26, 2021

Slight clarification:

From what I can tell, b802350 only applies to the "black-magic" ALT_ARCHS+= logic. I do no think it belongs in this PR.

It also sets up the LIBS+=-framework JavaVM, but from our testing, this is documented as "deprecated" based on the OS version (not based on the compiler version), so this PR uses the OS version instead. If the technique in this PR isn't acceptable, we can adopt the clang version parsing logic.

@tresf tresf force-pushed the darwin-arm64 branch 2 times, most recently from 8ed6e97 to ee6f6d9 Compare January 26, 2021 23:36
@tresf
Copy link
Contributor Author

tresf commented Jan 26, 2021

c783a4d should be doable, but due to code differences will probably lose accreditation.

Done via 1825df0, but merged into 6972631 and thanks to @Vzor- found out how to add attribution, so that's done as well.

We reverted the i386 part of the lib/native/darwin.jar, added back in aarch64. but something's gone wrong with the lipo step and x86_64 is currently missing. We'll fix that up asap. Edit: Fixed.

tresf and others added 5 commits January 26, 2021 20:03
Co-authored-by: Kyle Berezin <[email protected]>
Co-authored-by: Florian Kistner <[email protected]>
Arm64 calling convention requires varargs to always be passed on the stack. JNA's and ffi's argument handling logic seems to handle this case correctly, but it is important that the Java definitions match their native counterparts exactly.
Big Sur uses a shared dylib cache to lookup system libraries and frameworks. Checking existence in the file system will fail, but loading them will succeed nevertheless.
@raducoravu
Copy link

Is there a timeline for a JNA release which has support for darwin-arm?

@tresf
Copy link
Contributor Author

tresf commented Jan 27, 2021

Is there a timeline for a JNA release which has support for darwin-arm?

I think it's safe to say, it will land as soon as possible. 21 hours ago @matthiasblaesing said the following:

After [some items are] done, I should be able to rebuild the x86-64 binary with Xcode 9, the aarch64 binary with Xcode 12, and run unittests on x86-64. This will be merged and we can plan a release.

All items requested are done.

If anyone needs a version before that happens, please feel free to compile yourself. The documentation in this PR should be adequate to get you the files you need in snapshot form, which will contain the following architectures:

  libjnidispatch.jnilib (for architecture x86_64):      Mach-O 64-bit dynamically linked shared library x86_64
+ libjnidispatch.jnilib (for architecture arm64):       Mach-O 64-bit dynamically linked shared library arm64

Note, these steps can be done on an Intel or ARM Mac, but if cross-compiling, you'll need to provide the proper os.prefix, which is part of the documentation as well. Unit tests won't run when cross-compiling (this is intentional), but the resulting binary should be viable.

@matthiasblaesing matthiasblaesing merged commit dbbdb51 into java-native-access:master Jan 27, 2021
@matthiasblaesing
Copy link
Member

Merged to master - I had to do some additional fixes, as the changes to build.xml broke builds on windows. Apart from that looked good to me.

@raducoravu
Copy link

@matthiasblaesing thanks, I tested "Move to Trash" on Mac M1 with Java Zulu with the latest darwin jnilib and it seems to be working. I also tested it on an Intel-based Mac and seems to be working there as well.

@cricketsamya
Copy link

When is the plan to release this?

@dbwiddis
Copy link
Contributor

dbwiddis commented Feb 8, 2021

When is the plan to release this?

Per this post on the mailing list:

I'll let this settle a few days and aim for release in the second week of february.

@tresf
Copy link
Contributor Author

tresf commented Mar 24, 2021

Just an FYI on fast-forwarding/upstream status...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants