Skip to content

main/perl: upgrade to 5.36.0

rubicon requested to merge rubicon/aports:upgrade-perl-5.36 into master

Perl 5.36.0 builds successfully. However, on x86 (and 32-bit ARMs), it fail 2 tests in cpan/Compress-Raw-Zlib/t/02zlib.t: crc32_combine and adler32_combine.

Latest Edit: psykose has written the zlib patch to fix the z_off_t size mismatch on 32-bit platforms, I have written the patch for PostgreSQL's PL/Perl testsuite (the same patch needs to be applied to all 3 versions of Postgres), Claws-Mail has a working patch imported from Debian, and the CPAN modules that failed build/tests have been upgraded to versions that don't fail those.

So, I think this is quite ready. After this is merged, maintainers of pure Perl aports will need to see if their aports require any upgrades to be compatible with Perl 5.36.

6 aports that take a long time to compile have been moved to !35008 (merged) that can be merged after this one.


The aports being rebuilt in this MR either link directly to libperl.so, or have XS code (identified by looking for aports that have .so files in /usr/lib/perl5/vendor_perl/auto).


Out of 198 aports, 3 fail to build: claws-mail, perl-sereal-decoder, perl-sereal-encoder; and another 4 fail tests: postgresql12, postgresql13, postgresql14, perl-cpanel-json-xs.

On aarch64, perl-io-tty also fails tests due to sysread(): I/O error. Don't know if this is a one time occurrence.

Anyway, postgresql tests seem to be failing due to some changes in warning categories: the "useless use of sort in scalar context" warning has been moved from the void category to the new scalar category.

claws-mail's Perl plugin fails to build due to changes in macro definitions. From Debian, I found a bug report and a patch.

As for perl-cpanel-json-xs and perl-sereal-decoder/encoder, their latest versions (4.29 for cpanel-json-xs and 4.023 for sereal) build against Perl 5.36.0 successfully.


Addendum on Zlib: The armv7 and armhf builders seem to get stuck on the test that failed on x86 (cpan/Compress-Raw-Zlib/t/02zlib). Is there something going on with our zlib and 32-bit platforms?

For the record, Perl 5.36.0 upgrades its bundled Compress::Raw::Zlib from version 2.101 to 2.105.

There's also this line in main/perl/APKBUILD: rm -rf cpan/Compress-Raw-Zlib/zlib-src, so it seems Perl would normally use its own bundled zlib.

The funny thing is, there's a separate perl-compress-raw-zlib aport (that is included in this MR), and it uses its own bundled zlib-src and builds fine on x86. It is also at version 2.105.

For those more knowledgeable about Zlib, here's the output from the tests in Perl. This one is from the one failing, it is the same across all three 32-bit platforms. It is from the Compress::Raw::Zlib bundled in Perl 5.36.0, and as zlib-src has been deleted, it probably uses our main/zlib:

# 
# Compress::Raw::Zlib::VERSION        2.105
# 
# ZLIB_VERSION (from zlib.h)          1.2.12
# zlib_version (from zlib library)    1.2.12
# 
# ZLIB_VERNUM                         0x12C0
# BUILD_ZLIB                          0
# GZIP_OS_CODE                        3
# 
# zlibCompileFlags                    149
#   Type Sizes
#     size of uInt                    32 bit
#     size of uLong                   32 bit
#     size of pointer                 32 bit
#     size of z_off_t                 64 bit
#   Compiler Options                  None
#   One-time table building           None
#   Library content                   None
#   Operation variations              None
# 

This one is from the separate main/perl-compress-raw-zlib aport, using the zlib-src included with it. It is compiled with Perl 5.34.1 and succeeds:

# 
# Compress::Raw::Zlib::VERSION        2.105
# 
# ZLIB_VERSION (from zlib.h)          1.2.12
# zlib_version (from zlib library)    1.2.12
# 
# ZLIB_VERNUM                         0x12C0
# BUILD_ZLIB                          1
# GZIP_OS_CODE                        3
# 
# zlibCompileFlags                    85
#   Type Sizes
#     size of uInt                    32 bit
#     size of uLong                   32 bit
#     size of pointer                 32 bit
#     size of z_off_t                 32 bit
#   Compiler Options                  None
#   One-time table building           None
#   Library content                   None
#   Operation variations              None
# 

For more on this zlib z_off_t size mismatch on 32-bit platforms issue, have a look at comments: !34890 (comment 239130) and !34890 (comment 239272) .

Edited by rubicon

Merge request reports