Open perklet opened 7 months ago
That would require quite a lot of dependencies for compiling.
True, though in most cases it wouldn't be necessary since the prebuilts can be downloaded. I'm thinking it'd only require the dependencies on less commonly used platforms.
Alternatively, could skip using Zig for this and compile with system gcc on a s390x container, emulated via docker/qemu. I'm not sure what the minimum glibc is on s390x so it might not be necessary to use Zig just for pinning 2.17
According to this, s390[x] glibc had an abi breakage in 2.19, so that might be a safe minimum to aim for. https://lwn.net/Articles/605607/
Tried again to use Zig (to compile cpython) targeting s390x, it looks like the built-in llvm 17's linker does not support elf64_s390
and that was added in llvm 18. Until Zig upgrades llvm again, I would think a viable short-term solution is to use the gcc s390x cross compilation toolchain.
It probably would have worked if zig cc
supported using a different linker, but unfortunately that capability was intentionally omitted
@perklet mind if I take over on this PR? Latest zig nightly builds appear to have enough s390x support for a successful Python interpreter build, so I think this can also proceed
Thanks! assigned to you.
Unfortunate discovery: boringssl has no s390x support and has historically rejected patches to add support: https://boringssl-review.googlesource.com/c/boringssl/+/37544/1
I think there's nothing more we can do here until boringssl project revisits that decision, or there's a suitable replacement.
A possible option is to switch to this for just the s390x build: https://github.com/linux-on-ibm-z/boringssl/tree/patch-s390x-Aug2023
I've tried looking at using Zig to build for s390x on a different project, but wasn't successful. The compiler support isn't fully working. Perhaps it would be a better short term solution to have curl_cffi sdists compile libcurl-impersonate from source if it cannot find a precompiled binary?