Bug#1050592: perl: F_GETLK / F_GETLK64 confusion on ppc64el breaking libfile-fcntllock-perl
Aurelien Jarno
aurel32 at debian.org
Mon Aug 28 20:56:05 BST 2023
Hi Niko,
On 2023-08-27 14:43, Niko Tyni wrote:
> (full quote for the benefit of the Aurelien and other glibc maintainers)
>
> On Sat, Aug 26, 2023 at 09:07:38PM +0300, Niko Tyni wrote:
> > 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
Thanks for the details and the investigation.
> I think the relevant change here is this in libc6-dev_2.36-9+deb12u1 for bookworm:
>
> --- libc6-dev_2.36-9/usr/include/powerpc64le-linux-gnu/bits/fcntl.h 2023-04-10 09:35:16.000000000 +0100
> +++ libc6-dev_2.36-9+deb12u1/usr/include/powerpc64le-linux-gnu/bits/fcntl.h 2023-07-13 19:07:47.000000000 +0100
> @@ -33,6 +33,12 @@
> # define __O_LARGEFILE 0200000
> #endif
>
> +#if __WORDSIZE == 64
> +# define F_GETLK 5
> +# define F_SETLK 6
> +# define F_SETLKW 7
> +#endif
> +
Indeed you are correct that the issue has been introduced by this patch.
It fixes the case *without* -D_FILE_OFFSET_BITS=64, but OTOH breaks the
case *with* it.
> and a similar one in 2.37-2 for trixie/sid.
>
> The applicable changelog entry is presumably
>
> [ Aurelien Jarno ]
> * debian/patches/git-updates.diff: update from upstream stable branch:
> [...]
> - Not affecting bookworm release architectures:
> - Fix LFS POSIX lock constants for powerpc64.
>
> Aurelien, it seems that there's an oversight as ppc64el is a release architecture?
Yes, sorry about that. When reading the changelog and the diff, I
thought it was only for powerpc64, as ppc64el has a different ABI, but I
was wrong.
> I can see that this changed for the better, but what should I do with the above
> breakage? Rebuild perl and libfcntl-fcntllock-perl and declare some Breaks?
> Do we want to do that for stable too?
I think it's an ABI breakage that should be fixed, but just reverting
the patch will break the case without -D_FILE_OFFSET_BITS=64. I'll check
with upstream and try to get the issue fixed in both testing/sid and
stable. I'll keep you updated. In the meantime feel free to reassign the
bug to the glibc.
Regards
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien at aurel32.net http://aurel32.net
More information about the Perl-maintainers
mailing list