Bug#1067241: perl: time64 build flags should go in $Config{ccflags}

Niko Tyni ntyni at debian.org
Wed Mar 20 18:31:57 GMT 2024


Package: perl
Version: 5.38.2-3.2
Tags: patch
User: debian-arm at lists.debian.org
Usertags: time-t
X-Debbugs-Cc: Steve Langasek <vorlon at debian.org>

[ Steve: I'm sure you have bigger fish to fry but FYI anyway.
  Apologies for the imbalance between verbosity and importance.
  Comments welcome of course. ]

On the architectures affected by the time64 transition (32-bit !*i386),
I think we should store the relevant build flags[*] in %Config to make
sure XS (binary) modules get built with them.

[*] just -D_TIME_BITS=64 I think as the LFS flags are included already

This would have been critical if we were still relying on just
dpkg-buildflags to inject the flags: in that case, modules installed
from CPAN outside dpkg package management would have got misbuilt and
incompatible with the Perl interpreter (because the Perl interpreter
C structure includes a time_t field so its size affects the binary
interface between Perl and its modules.)

However, I understand gcc now sets the time64 flags by default. With
that I think this is mostly cosmetic as long as people use the normal
system compiler. So filing at severity:normal.

I'd still like to fix it so that %Config includes flags required for
binary compatibility between Perl and its binary modules, for transparency
and robustness. For instance, I can imagine someone trying to build CPAN
modules with a non-default compiler and wasting a lot of time because
we currently hide the flags.

I'm attaching an untested simple patch that I think should do it.
Full disclosure: it affects the flags that all XS modules get built
with, although those flags were in my understanding already implied for
current builds.  Even so, I'm not quite sure if I should refrain from
adding them at this stage of the time64 transition.

If we decide not to do this at this time, I'm fine with postponing this
for the upcoming Perl 5.40 transition later this year, where all those
packages will get rebuilt anyway for Debian trixie. The downside with
that is that the upcoming Ubuntu LTS release will not have them (and
possibly it's too late for that now anyway.)

Some more detailed background follows.

Perl generally stores its C compiler and linker flags in
$Config{ccflags} and $Config{lddlflags} respectively.

  % perl -V:ccflags  
  ccflags='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64';
  % perl -V:lddlflags
  lddlflags='-shared -L/usr/local/lib -fstack-protector-strong';
  
These are passed on to XS module builds by ExtUtils::MakeMaker and
Module::Build to ensure that the resulting binary modules are compatible
with the Perl interpreter they were built for.

However, this mechanism is somewhat at odds with opt-in build flags such
as hardening, where we generally want to build perl itself with them but
don't want to force them on all XS module packages because they might
not be ready for them. We discussed this at length back in #657853 and
ended up with a solution where we filter away dpkg-buildflags induced
flags and don't store them in %Config, assuming that XS module packages
will get them from dpkg-buildlags themselves.

This was all fine until now, but the time64 flags are not opt-in like the
hardening flags because they affect the binary interface between Perl
and binary modules. So these flags need to be active in all XS module
builds, whether they want them or not, and therefore I don't think we
should filter them away like the others.
-- 
Niko Tyni   ntyni at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Include-time64-build-flags-in-Config-ccflags.patch
Type: text/x-diff
Size: 921 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/perl-maintainers/attachments/20240320/4b7958c7/attachment.patch>


More information about the Perl-maintainers mailing list