[query] universal dylibs for OS X (and update prebuilt) #14006
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
CHANGELOG: Hail supports identity_by_descent on Apple M1 and M2 chips; however, your Java installation must be an arm64 installation. Using x86_64 Java with Hail on Apple M1 or M2 will cause SIGILL errors. Fixes (hail#14000). Fixes hail-is#14000 Hail has never supported its native functionality on Mac OS X Apple M1 chips. In particular, we only built x86_64 compatible dylibs. M1 chips will try to simulate a very basic x86_64 ISA using Rosetta 2 but our x86_64 dylibs expect the ISA of at least sandybridge, which includes some SIMD instructions not supported by Rosetta 2. This PR bifurcates our native build into x86_64 and arm64 targets which live in build/x86_64 and build/arm64, respectively. In Linux, this moves where the object files live, but should otherwise have no effect. The test and benchmark targets use the "native" build which always points at the x86_64 object files. The shared object targets, LIBBOOT & LIBHAIL, explicitly depend on x86_64 because that is the only linux architecture we support. In OS X, we only test and benchmark the "native" build, which is detected using `uname -m`. For the shared objects (the dylibs) we have four new files: libboot and libbhail for x86_64 and for arm64. Each pair files is placed in `darwin/x86_64/` and `darwin/arm64/`, respectively. Those dylibs are never meant to escape the src/main/c world. The LIBBOOT and LIBHAIL targets (which are invoked by hail/Makefile) combine the two architecture-specific dylibs into a "universal" dylib. You can verify this by running `file` on the dylibs. Here I run them on the new "prebuilt" files which are in this PR: ``` (base) dking@wm28c-761 hail % file hail/prebuilt/lib/darwin/libboot.dylib hail/prebuilt/lib/darwin/libboot.dylib: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit dynamically linked shared library x86_64] [arm64:Mach-O 64-bit dynamically linked shared library arm64] hail/prebuilt/lib/darwin/libboot.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64 hail/prebuilt/lib/darwin/libboot.dylib (for architecture arm64): Mach-O 64-bit dynamically linked shared library arm64 (base) dking@wm28c-761 hail % file hail/prebuilt/lib/darwin/libhail.dylib hail/prebuilt/lib/darwin/libhail.dylib: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit dynamically linked shared library x86_64] [arm64:Mach-O 64-bit dynamically linked shared library arm64] hail/prebuilt/lib/darwin/libhail.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64 hail/prebuilt/lib/darwin/libhail.dylib (for architecture arm64): Mach-O 64-bit dynamically linked shared library arm64 ``` @chrisvittal , I need you to test this new makefile in Linux: ``` make -C hail pytest HAIL_COMPILE_NATIVES=1 PYTEST_ARGS='-k test_ibd_does_not_error_with_dummy_maf_float64' ``` I am fairly certain this Makefile will not work on old macbooks because they cannot compile for Apple M1. This means that we always need someone with an Apple M1 macbook to build the prebuilts. *A MAJOR CAVEAT OF THIS CHANGE*: Users of Apple M1 macbooks must upgrade to an arm64 JVM. They *must not* use Rosetta 2 to simulate an x86_64 JVM. In particular, this means that Apple M1 users must upgrade to JVM 11 because there are [no Adopt OpenJDK JVMs for arm64](https://adoptium.net/temurin/releases/?version=8&os=mac).
|
Don't approve until I figure out what to do for old macbooks. AFAIK, they can't cross build for Apple M1s, but I want to at least make it possible to build a non-universal dylib on an old MacBook. https://gist.github.com/jigold/17b2ffc817cbe9966b9587e9e2294d08 |
|
Pending confirmation from Daniel, I believe I've addressed the Intel Mac & GNU/Linux issues. |
|
This works on an x86 Mac as well: https://hail.zulipchat.com/#narrow/stream/127527-team/topic/Old.20macbooks/near/404492651 Ready for review, sent to Chris since he's probably got the most context on building native libs. |
|
@chrisvittal bump |
chrisvittal
approved these changes
Nov 28, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
CHANGELOG: Hail supports identity_by_descent on Apple M1 and M2 chips; however, your Java installation must be an arm64 installation. Using x86_64 Java with Hail on Apple M1 or M2 will cause SIGILL errors. If you have an Apple M1 or Apple M2 and
/usr/libexec/java_home -Vdoes not include(arm64), you must switch to an arm64 version of the JVM. Fixes (hail#14000).Fixes #14000
Hail has never supported its native functionality on Mac OS X Apple M1 chips. In particular, we only built x86_64 compatible dylibs. M1 chips will try to simulate a very basic x86_64 ISA using Rosetta 2 but our x86_64 dylibs expect the ISA of at least sandybridge, which includes some SIMD instructions not supported by Rosetta 2.
This PR bifurcates our native build into x86_64 and arm64 targets which live in build/x86_64 and build/arm64, respectively.
In Linux, this moves where the object files live, but should otherwise have no effect. The test and benchmark targets use the "native" build which always points at the x86_64 object files. The shared object targets, LIBBOOT & LIBHAIL, explicitly depend on x86_64 because that is the only linux architecture we support.
In OS X, we only test and benchmark the "native" build, which is detected using
uname -m. For the shared objects (the dylibs) we have four new files: libboot and libbhail for x86_64 and for arm64. Each pair files is placed indarwin/x86_64/anddarwin/arm64/, respectively. Those dylibs are never meant to escape the src/main/c world. The LIBBOOT and LIBHAIL targets (which are invoked by hail/Makefile) combine the two architecture-specific dylibs into a "universal" dylib. You can verify this by runningfileon the dylibs. Here I run them on the new "prebuilt" files which are in this PR:@chrisvittal , I need you to test this new makefile in Linux:
I am fairly certain this Makefile will not work on old macbooks because they cannot compile for Apple M1. This means that we always need someone with an Apple M1 macbook to build the prebuilts.
A MAJOR CAVEAT OF THIS CHANGE: Users of Apple M1 macbooks must upgrade to an arm64 JVM. They must not use Rosetta 2 to simulate an x86_64 JVM. In particular, this means that Apple M1 users must upgrade to JVM 11 because there are no Adopt OpenJDK JVMs for arm64.