yihua opened a new issue, #756: URL: https://github.com/apache/hudi-rs/issues/756
The linux wheels build on `manylinux2014`, whose CentOS 7 base predates every native toolchain need this project has grown. Getting 0.5.0 to build there (#750, #751) required downloading protoc (distro version 2.5.0), installing libclang from an LLVM 7 software collection, and handing bindgen the library path and builtin-header include explicitly because the SCL layout defeats libclang's own resource lookup. The aarch64 step additionally carries `CFLAGS_aarch64_unknown_linux_gnu="-D__ARM_ARCH=8"` for ring, with a comment saying it can go once the image moves to 2_28. Moving to `manylinux_2_28` (AlmaLinux 8) removes all of that except the pinned protoc download (the 8.x distro protoc is 3.5, still too old): the distro `clang-devel` is clang 21 and bindgen finds it with no environment handed in, and ring compiles without the CFLAGS workaround. Verified in `quay.io/pypa/manylinux_2_28`: `lance-encoding` 11.0.0, `librocksdb-sys` 0.16.0 and `ring` 0.17.14 all compile clean. The cost is the wheel floor moving from glibc 2.17 to 2.28, dropping CentOS 7, Ubuntu 18.04, and Amazon Linux 2, all past end of life. In practice nothing is lost: pyarrow, numpy, and the datafusion python package, the packages hudi wheels run alongside, ship `manylinux_2_28` wheels only, so any environment excluded by the new floor already cannot install the surrounding stack. Targeting 0.6.0: the 0.5.0 release ships from `manylinux2014` (#751) so the floor does not change mid-release, and 0.5.0 already raises the Python floor to 3.10, so the two compatibility changes land in separate releases. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
