-
-
Notifications
You must be signed in to change notification settings - Fork 30k
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
Assertion failure in test_capi test_alignof_max_align_t possible with macOS universal2 (multi-arch) builds #110820
Comments
The easiest fix here is to do something similar as was done for other CPU specific defines on macOS: use pymacconfig.h to hardcode the expected values. |
… Universal 2 build on macOS A number of processor specific defines are different for x86-64 and arm64, and need to be adjusted in pymacconfig.h.
The attached PR synchronises the various macros with reality through pymacconfig.h, except for PY_SUPPORT_TIER could also be fixed, but through |
I wouldn't worry about |
… Universal 2 build on macOS (python#112828) * pythongh-110820: Make sure processor specific defines are correct for Universal 2 build on macOS A number of processor specific defines are different for x86-64 and arm64, and need to be adjusted in pymacconfig.h. * remove debug stuf (cherry picked from commit 15a80b1)
3.12 backport PR is #112864. This is a manual back port based on work by cherry_pick (but with significant manual work because I managed to confuse that tool somehow) |
As mentioned in #112828 it is my opinion that backporting to 3.11 is not useful, I'm therefore closing this issue. Please reopen if there is a reason to do a back port to 3.11.
|
… Universal 2 build on macOS (python#112828) * pythongh-110820: Make sure processor specific defines are correct for Universal 2 build on macOS A number of processor specific defines are different for x86-64 and arm64, and need to be adjusted in pymacconfig.h. * remove debug stuf
… Universal 2 build on macOS (python#112828) * pythongh-110820: Make sure processor specific defines are correct for Universal 2 build on macOS A number of processor specific defines are different for x86-64 and arm64, and need to be adjusted in pymacconfig.h. * remove debug stuf
macOS supports multi-architecture binaries (fat binaries) and CPython have long supported building them. Current releases of macOS support two system architectures: legacy x86_64 (for Intel Macs) and arm64 (for Apple Silicon Macs). The CPython ./configure supports building fat binaries containing both archs by use of the
--with-universal-archs=universal2
option. To do so, it makes use of the muilt-arch support built into the Apple-supplied build tools (Xcode or Command Line Tools) which allows multi-arch compiles and links to happen via single calls (by adding --arch flags to the calls to compilers et al).However, because configure's autoconf tests are only run in the architecture of the build machine, different results can be obtained depending on whether the
universal2
build machine is an Intel or an Apple Silicon Mac. In particular, there are differences in the autoconf generatedpyconfig.h
as shown here with modified file names for clarity; in either case, there is only onepyconfig.h
file that will be generated and used regardless of which arch the fat binaries are run on:The difference in
ALIGNOF_MAX_ALIGN_T
between the two archs leads to the following test failure when a universal2 binary is built on an Apple Silicon Mac but executed on an Intel Mac:The test does not crash in the opposite case: when built on an Intel Mac but run on an Apple Silicon Mac, because in this case 16 > 8.
This issue was noticed while testing changes to the process we use to build python.org python for macOS installers. Up to now, we have been using Intel Macs to build all installers but, when testing building installers on Apple Silicon Macs, the crash of
test_capi
was seen when running the resultantuniversal2
installer on Intel Macs.It's not clear what is the best way to resolve this and, more importantly, whether there are other kinds of similar problems not yet discovered. Probably the safest approach would be to build each architecture separately on their native archs and
lipo
the resultant single-arch binaries into fat files. And/or it may be better to provide separate copies of arch-sensitive header files like pyconfig.h in separate directories and have the interpreter point to the correct one at run time for extension module builds. Or, in this case, perhaps adding some some conditional code to force the sizes to be the larger value in the case of macOS universal2 builds might be enough this time?Linked PRs
The text was updated successfully, but these errors were encountered: