Fix failing Linux jobs

[radarhere]

Linux jobs in master are currently failing - https://github.com/python-pillow/pillow-wheels/runs/3674659897?check_suite_focus=true#step:4:3512

/opt/rh/devtoolset-10/root/usr/libexec/gcc/x86_64-redhat-linux/10/ld: ./.libs/libpng16.so: undefined reference to `inflateValidate'

This is due to an older version of zlib being used, so I put together a commit to remove the existing version, so that our built version will be used instead.

However, that lead to a different error - https://github.com/radarhere/pillow-wheels/runs/3686958074?check_suite_focus=true#step:4:6598

auditwheel: error: cannot repair "/io/wheelhouse/Pillow-8.3.2-cp310-cp310-linux_x86_64.whl" to "manylinux2014_x86_64" ABI because of the presence of too-recent versioned symbols. You'll need to compile the wheel on an older toolchain.

I suspect this is all related to the recent release of auditwheel 5.0. Adding another commit to downgrade auditwheel to less than 5, master begins passing again.

[hugovk]

Should it also be reported to auditwheel?

[radarhere]

If I add the --verbose flag to auditwheel, I get messages like

DEBUG:auditwheel.policy.versioned_symbols:Package requires ZLIB_1.2.9, incompatible with policy manylinux_2_24_i686 which requires {'ZLIB_1.2.5.2', 'ZLIB_1.2.0.2', 'ZLIB_1.2.0', 'ZLIB_1.2.3.4', 'ZLIB_1.2.2.4', 'ZLIB_1.2.3.3', 'ZLIB_1.2.0.8', 'ZLIB_1.2.5.1', 'ZLIB_1.2.2', 'ZLIB_1.2.3.5', 'ZLIB_1.2.2.3'}

According to https://github.com/pypa/auditwheel/blob/main/src/auditwheel/policy/manylinux-policy.json, to use zlib 1.2.9, one must use manylinux_2_27. The "ZLIB" entries were added in pypa/auditwheel#334.

According to https://github.com/mayeut/pep600_compliance, manylinux_2_27 means Ubuntu 18.04. We are currently providing manylinux_2_17 (Ubuntu 13.04), so that is an upgrade in our minimum requirements. It doesn't seem unreasonable though, since 16.04 has already reached of end of standard support.

But then there is a problem testing on 32-bit, since we would have to upgrade from testing on trusty, and https://github.com/multi-build/docker-images doesn't provide 32-bit focal images.

I don't know what the feeling is about going down that route.

[matthew-brett]

Numpy is currently proposing to drop 32-bit wheels, if that's relevant ...

[hugovk]

@radarhere Thanks for digging into all that!

Dropping 32-bit: let's open an issue in the main repo to discuss it, will be more eyes over there.

I'd say we should drop 32-bit at some point, depending on download numbers and what the Python community at large is doing, and was about to suggest NumPy as an example so thank you @matthew-brett that does help!

We have an 8.4.0 release due this Friday, which is too short notice to consider dropping, but the January quarterly release is a major bump 9.0.0 so let's see about then (I don't think it necessarily has to coincide with a major bump if we do it later next year).

Anyway, let's merge this for now, if nothing else we need to unblock this week's release. :)

Thanks again!