GeezerVison

The logic looks good to me, but I wonder if this ends up enabling Blake2s/128 on ARM64? Right now it's not enabled (due to a slow barrel-shifter, I think, which gives so-so performance) by default, but might end up being enabled unintentionally for universal builds.

Also, I don't know if this is specific to this work, but I tried out ./configure --with-builtin-hashlib-hashes=md5,sha1,sha2,sha3,blake2 but then when I tried to make sure built-in hashes were linked properly, I got this:

>>> import hashlib
>>> hashlib.sha256
<built-in function openssl_sha256>

(not sure this is related to the problem of universal builds, or if this is a more general issue with configure)

The logic looks good to me, but I wonder if this ends up enabling Blake2s/128 on ARM64? Right now it's not enabled (due to a slow barrel-shifter, I think, which gives so-so performance) by default, but might end up being enabled unintentionally for universal builds.

It will - unlike SIMD256.c, SIMD128.c can be compiled on ARM64. However, given the existing configuration, it wouldn't be included in an ARM64-only build. I'll push an update to do a similar "#include and #undef" trick for the SIMD128 implementation so that we retain parity with single-architecture builds.

Also, I don't know if this is specific to this work, but I tried out ./configure --with-builtin-hashlib-hashes=md5,sha1,sha2,sha3,blake2 but then when I tried to make sure built-in hashes were linked properly, I got this:

>>> import hashlib
>>> hashlib.sha256
<built-in function openssl_sha256>

(not sure this is related to the problem of universal builds, or if this is a more general issue with configure)

This is the same behavior I see in the official universal build of Python 3.13.0rc2 running on macOS. The same is true of other older Pythons that I've tested back to 3.8, so it doesn't appear to be specific to this patch.

@msprotz Are you happy with the current state of this patch?