Add zstd support for Python 3.14+ on Unix

[zanieb]

This task was deferred from the initial Python 3.14 support. There's already support on Windows.

[indygreg]

@Cyan4973 there is a musl workaround patch in this PR that may interest you.

Our build environment is quite esoteric though (clang on ancient Debian), so please apply scrutiny.

[zanieb]

This is modeled off of

python-build-standalone/cpython-unix/build-cpython.sh

Lines 410 to 422 in 13731b0

	# In order to build the _blake2 extension module with SSE3+ instructions, we need
	# musl-clang to find headers that provide access to the intrinsics, as they are not
	# provided by musl. These are part of the include files that are part of clang.
	# But musl-clang eliminates them from the default include path. So copy them into
	# place.
	for h in /tools/${TOOLCHAIN}/lib/clang/*/include/*intrin.h /tools/${TOOLCHAIN}/lib/clang/*/include/{__wmmintrin_aes.h,__wmmintrin_pclmul.h,mm_malloc.h,cpuid.h}; do
	filename=$(basename "$h")
	if [ -e "/tools/host/include/${filename}" ]; then
	echo "${filename} already exists; don't need to copy!"
	exit 1
	fi
	cp "$h" /tools/host/include/
	done

[zanieb]

Annoyingly, I didn't realize this was the problem until I was pretty far in. We might want to generalize this at some point, e.g., by fixing musl-clang or rolling our own.

[geofft]

Yeah I've been wanting to do that, filed #684.

On a separate note - I assume zstd is smart enough to correctly detect availability of the intrinsics and we don't need to patch these out for x86-64-v1? I guess put another way, do we have tests that our x86-64-v1 builds don't include things that aren't supported on that microarch? If not we should add some (either with objdump or I think qemu can do it with machine options).

[zanieb]

I assume zstd is smart enough to correctly detect availability of the intrinsics and we don't need to patch these out for x86-64-v1?

Things looked properly gated from the poking around I did to get this working. I don't know of explicit test coverage.

[geofft]

LGTM

[geofft]

Yeah I've been wanting to do that, filed #684.

On a separate note - I assume zstd is smart enough to correctly detect availability of the intrinsics and we don't need to patch these out for x86-64-v1? I guess put another way, do we have tests that our x86-64-v1 builds don't include things that aren't supported on that microarch? If not we should add some (either with objdump or I think qemu can do it with machine options).

[geofft]

It's in 1.2.3, but I guess we're on 1.2.2 for compatibility with older systems of some sort?

[zanieb]

That's funny. Yeah we're on the oldest version we can use for compatibility with old systems since we dynamically link now. We can probably upgrade at some point though.

[zanieb]

I'll update that comment.

[geofft]

I guess the trouble here is that musl (intentionally) does not expose any sort of version information in headers, and so if you want to figure out whether the target musl supports qsort_r, then you have to do ./configure-style feature detection, and zstd (understandably) doesn't do that and only has a Makefile that you run directly. So I'm not actually sure there's anything I'd advocate changing in zstd upstream.