Closed rgaudin closed 10 months ago
Issue is serious as it concerns all our aarch64 wheels.
Due to glibc-usage, we have decided to support the manylinux_2_28
platform for Python 3.8-3.11 (3.7 is now EOL).
This means that our binary libzim (and the wrapper) should be compatible (and thus use at most) glibc 2.28.
For this reason, we are building libzim on Ubuntu bionic (glibc 2.27) and our wrapper is built on manylinux_2_28 (glibc 2.28).
pylibzim 3.1.0 (May 1st 2023) uses libzim 8.2.0 (release)
aarch64
ones are actually 2_24
compatible (auditwheel
renames to match the minimum satisfying version)Rebuilding with libzim 8.2.0 works as expected but 8.2.1 doesn't.
auditwheel
finds symbols requiring glibc 3.4 which is not acceptable (Debian 12+/ Ubuntu 22.04+/ Fedora 35+). This is due to the recent version of GCC (libstdc++ declaring GLIBCXX_3.4.29
) used by the cross-compilation toolchain introduced in https://github.com/kiwix/kiwix-build/pull/615
I've rebuilt libzim (main
) and all its dependencies using the previous compiler and it produces an acceptable libzim that works as expected.
Follow-up action (@mgautierfr) is thus to fix this regression on kiwix-build. Beside pylibzim, it is likely that it's not possible to link libzim at all on focal neither. zim-tools
and kiwix-tools
are not affected as those are static binaries.
It's important to document which version we want to support and why.
There is currently no Kiwix/openZIM policy AFAIK but my rule has been: support only still-maintained Python releases. Regarding system (important here as we're distributing a binary), support earliest still maintained Debian version.
Kiwix-build recently switched to building on Ubuntu 20.04 focal. Focal uses glib 2.31, as well as Debian 11 Bullseye (as well as Fedora 32+).
@rgaudin It seems there is no blicker to implement this ticket anymore? Or domwe have another ticket on kiwix-build which needs to be implememted?
This is being tested in the CI as we speak…
Fixed and merged
this run failed with