Compilation of HACL fails under macOS Silicon for version 3.14

[naizhao]

Bug report

Bug description:

Related issues: #123748, #130366, #129043

Problem:
In Python 3.14.0a5, when compiling on macOS Silicon without specifying the --enable-universalsdk parameter (as there is no need to compile a universal version for x86_64 & arm64), an error "unknown type name 'Lib_IntVector_Intrinsics_vec256'" occurs.

Compilation parameters:

./configure --prefix=/Applications/ServBay/package/python/3.14/3.14.0a5 --enable-ipv6 --enable-loadable-sqlite-extensions --with-openssl=/Applications/ServBay/package/common/openssl/3.2 --enable-optimizations --with-system-expat --with-system-libmpdec --with-readline=editline --with-lto --enable-framework=/Applications/ServBay/package/python/3.14/3.14.0a5

Problem analysis:
The Python team previously released a patch for this issue, but in the configure and configure.ac scripts, the patch uses the $UNIVERSAL_ARCHS parameter for condition checks. This fix does not completely resolve the issue because $UNIVERSAL_ARCHS depends on the --enable-universalsdk parameter being passed. Without this parameter, the initial value of $UNIVERSAL_ARCHS is UNIVERSAL_ARCHS="32-bit", leading to the condition if test "$UNIVERSAL_ARCHS" != "universal2"; then not being effective.

Partial configure log:

Python 3.9+ detected
checking build system type... aarch64-apple-darwin23.5.0
checking host system type... aarch64-apple-darwin23.5.0
checking for Python interpreter freezing... ./_bootstrap_python
checking for python3.14... no
checking for python3.13... no
checking for python3.12... python3.12
checking Python for regen version... Python 3.12.5
checking pkg-config is at least version 0.9.0... yes
checking MACHDEP... "darwin"
checking for --enable-universalsdk... no
checking for --with-universal-archs... no
checking for --with-app-store-compliance... not patching for app store compliance
checking for xcrun... yes
checking macOS SDKROOT... /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether the compiler supports GNU C... yes
checking whether gcc accepts -g... yes
checking for gcc option to enable C11 features... none needed
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for a sed that does not truncate output... /usr/bin/sed
checking for egrep... /usr/bin/grep -E
checking for CC compiler name... clang

// blablabla

Repair solution:
In the configure and configure.ac scripts, it is necessary to use other conditions for checks instead of relying on $UNIVERSAL_ARCHS.
Attached is a quick fix patch based on build_cpu and build_vendor. However, this is not the most appropriate solution.
https://github.com/user-attachments/files/18921691/fixed-hacl-arm64.patch

CPython versions tested on:

3.14

Operating systems tested on:

macOS

[picnixz]

cc @msprotz @gpshead

[msprotz]

Thank you for filing this report.

However, this is not the most appropriate solution.

Can you say why?

[naizhao]

Thank you for filing this report.

However, this is not the most appropriate solution.

Can you say why?

The patch solves the problem by hardcoding $build_cpu and $build_vendor, which is a dirty fix. I am not sure if the Python team has other variables that could provide a better fix.

[picnixz]

Does HACL* now compile correctly with the latest main? we improved the build (not for macOS explicitly though) but maybe it solves your issue now?