You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We support fat builds of Python on macOS, in particular used for the "Universal 2" installers on macOS (configure --enable-universalsdk --with-universal-archs=universal2). This uses clang's builtin support for compiling multiple architectures in one go (e.g. clang -arch arm64 -arch x86_64 ...).
As far as I can see now the machinery for JIT (--enable-experimental-jit) does not support this at the moment.
On possible way to get this to work (untested and likely incomplete) is to generate multiple variants for jit_stencils.h when doing a fat build and generate an umbrella header that includes the right one:
Something that should be fixed (or figured out) first is getting --with-universal-archs with just one platform to work correctly. For example, if I'm on an M2 Mac and ./configure --enable-universalsdk --with-universal-archs=intel-64, the host configure var is set to aarch64-apple-darwin23.2.0 (it even prints out a message that I'm building for a tier two platform).
host is what's used to build the JIT, so mayhem ensues. Maybe we should use a new var, that can hold several space-separated values?
Once we have cross-builds on one platform working on macOS, it probably wouldn't be too hard to build two (or more!) JITs from there by passing several platforms to the build script.
I'm happy to take on the JIT side of this project. Can somebody else figure out the prerequisite configure stuff? :)
The patch below teaches configure.ac about mixing --experimental-jit and --with-universal-archs. The Tools/jit/build.py script will get called with multiple target triples (except for intel-64 and intel-32 which describe only 1 architecture).
I had to move handling --with-universal-archs to below handling --with-universal-archs, other than that the change it fairly mundane. Setting ARCH_TRIPPLES is a bit weird, mostly done this way to save some typing.
BTW. The patch can result in calling the JIT tooling with a number of ancient Mac architectures (like PPC and i386), feel free to error out on those. IMHO we should remove those from configure entirely, but that's for a different issue.
@brandtbucher, I've added a draft PR that seems to work for me (that is, a universal2 build works and won't crash for both light interactive use and a partial test run for both arm64 and x86_64).
The PR is a bit rough and contains one unrelated change due using the compiler included in Xcode (not command line tools) and installing llvm-16 manually and not through homebrew.
I was digging into this a bit but wanted to ask a perhaps naive question unrelated to JIT-specific builds: is there a reason we have FAT builds for Mac but not Windows?
I can see the benefits of a universal installer from an end-user perspective, as some users might not know which architecture they're using. However, universal installers also have downsides, such as increased binary size.
Has there been any discussion about providing separate installers for Mac x86 and ARM architectures?
Activity
brandtbucher commentedon Feb 1, 2024
I agree that we should support this.
Something that should be fixed (or figured out) first is getting
--with-universal-archswith just one platform to work correctly. For example, if I'm on an M2 Mac and./configure --enable-universalsdk --with-universal-archs=intel-64, thehostconfigure var is set toaarch64-apple-darwin23.2.0(it even prints out a message that I'm building for a tier two platform).hostis what's used to build the JIT, so mayhem ensues. Maybe we should use a new var, that can hold several space-separated values?Once we have cross-builds on one platform working on macOS, it probably wouldn't be too hard to build two (or more!) JITs from there by passing several platforms to the build script.
I'm happy to take on the JIT side of this project. Can somebody else figure out the prerequisite
configurestuff? :)ronaldoussoren commentedon Feb 19, 2024
The patch below teaches
configure.acabout mixing--experimental-jitand--with-universal-archs. TheTools/jit/build.pyscript will get called with multiple target triples (except forintel-64andintel-32which describe only 1 architecture).I had to move handling
--with-universal-archsto below handling--with-universal-archs, other than that the change it fairly mundane. SettingARCH_TRIPPLESis a bit weird, mostly done this way to save some typing.BTW. The patch can result in calling the JIT tooling with a number of ancient Mac architectures (like PPC and i386), feel free to error out on those. IMHO we should remove those from configure entirely, but that's for a different issue.
ronaldoussoren commentedon Feb 20, 2024
@brandtbucher, I've added a draft PR that seems to work for me (that is, a universal2 build works and won't crash for both light interactive use and a partial test run for both arm64 and x86_64).
The PR is a bit rough and contains one unrelated change due using the compiler included in Xcode (not command line tools) and installing llvm-16 manually and not through homebrew.
savannahostrowski commentedon Sep 14, 2024
I was digging into this a bit but wanted to ask a perhaps naive question unrelated to JIT-specific builds: is there a reason we have FAT builds for Mac but not Windows?
I can see the benefits of a universal installer from an end-user perspective, as some users might not know which architecture they're using. However, universal installers also have downsides, such as increased binary size.
Has there been any discussion about providing separate installers for Mac x86 and ARM architectures?
GH-114809: Add support for macOS multi-arch builds with the JIT enabl…