Bug#1050592: perl: F_GETLK / F_GETLK64 confusion on ppc64el breaking libfile-fcntllock-perl

Niko Tyni ntyni at debian.org
Sat Aug 26 19:07:38 BST 2023


Package: perl
Version: 5.36.0-8
Severity: serious
X-Debbugs-Cc: debian-powerpc at lists.debian.org
Control: affects -1 libfile-fcntllock-perl

Hi,

debugging an unexpected autopkgtest failure of
libfile-fcntllock-perl_0.22-4+b1 with perl_5.36.0-8 on ppc64el [1] I found
it's because the old perl binary (5.36.0-7) was built with the fcntl(2)
constant F_GETLK == 12, but the new one with F_GETLK == 5 [2].

There are no source or build system changes in perl that would have caused
this change. The failure is currently blocking perl testing migration,
so filing at 'serious'.

Perl is built with -D_FILE_OFFSET_BITS=64, and I see that on bullseye
this causes F_GETLK == F_GETLK64 == 12, but on bookworm and later
F_GETLK == 5 while F_GETLK64 == 12 [3]. I didn't find the exact
change that caused this yet.

As can be expected from the above, building libfile-fcntllock-perl on
bookworm against perl_5.36.0-7 makes it fail its test suite in a similar
way. And rebuilding it on sid against perl_5.36.0-8 makes it pass.

On amd64 the constants have stayed equal (== 5) from bullseye to sid,
and _FILE_OFFSET_BITS=64 doesn't affect them. What's the deal on ppc64el?

Copying the powerpc porters list. Could you please look into this?

[1] https://ci.debian.net/data/autopkgtest/unstable/ppc64el/libf/libfile-fcntllock-perl/34669085/log.gz
[2] perl -MPOSIX -E 'say F_GETLK'
[3] printf '#include <fcntl.h>\nF_GETLK\nF_GETLK64\n' | cpp -D_FILE_OFFSET_BITS=64 | tail -2

-- 
Niko Tyni   ntyni at debian.org




More information about the Perl-maintainers mailing list