Re: Bug#1030827: FTBFS on armhf

[Friedrich Beckmann]

Dear Niko,

thanks for figuring out the problem! I will disable the perl-module
for the moment.

Thanks!

Friedrich

> Am 10.02.2023 um 20:53 schrieb Niko Tyni <ntyni@debian.org>:
> 
> Control: severity -1 serious
> Justification: fails to build from source
> 
> On Tue, Feb 07, 2023 at 03:47:46PM -0500, Sergio Durigan Junior wrote:
>> Source: pspp
>> Severity: important
>> Version: 1.6.2-1
> 
>> pspp is currently FTBFSing on armhf due to several Perl-related tests
>> failing with:
>> 
>> --8<---------------cut here---------------start------------->8---
>> +PSPP.c: loadable library and perl binaries are mismatched (got first 
>> handshake key 0xa500080, needed 0xa400080)
>> --8<---------------cut here---------------end--------------->8---
>> 
>> You can see the build log by inspecting reproducible-build's page:
>> 
>>  https://tests.reproducible-builds.org/debian/rb-pkg/unstable/armhf/pspp.html
> 
> Hi, this is about 64-bit time_t, which became supported in glibc 2.34.
> 
>  https://sources.debian.org/src/glibc/2.34-7/NEWS/#L171
> 
>  * Add support for 64-bit time_t on configurations like x86 where time_t
>    is traditionally 32-bit.  Although time_t still defaults to 32-bit on
>    these configurations, this default may change in future versions.
>    This is enabled with the _TIME_BITS preprocessor macro set to 64 and is
>    only supported when LFS (_FILE_OFFSET_BITS=64) is also enabled.  It is
>    only enabled for Linux and the full support requires a minimum kernel
>    version of 5.1.
> 
> Perl itself is built with 32-bit time_t on Debian 32-bit architectures
> (like armhf and i386), but the pspp configure script probes and enables
> 64-bit time_t:
> 
>  checking for 64-bit time_t with _TIME_BITS=64... yes
> 
> This ends up in config.h and changes the size of the Perl interpreter
> structure around for example
> 
>  https://sources.debian.org/src/perl/5.36.0-7/intrpvar.h/#L506
> 
> making the resulting compiled Perl module binary incompatible with
> /usr/bin/perl .
> 
> I expect that configuring explicitly with --disable-year2038 would
> be a quick fix.
> 
> Longer term, we might want to start building Perl with a 64-bit time_t,
> but that's clearly stuff for the next development cycle (bookworm + 1).
> 
> BTW, would it make sense to install the PSPP Perl module in the pspp
> binary package (or a separate libpspp-perl or whatever?) Currently
> it looks like you're building it just for running the tests but then
> throwing the result away.
> 
> Hope this helps, and thanks for your work on Debian.
> -- 
> Niko Tyni   ntyni@debian.org