[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bug#1030827: FTBFS on armhf

From: Friedrich Beckmann
Subject: Re: Bug#1030827: FTBFS on armhf
Date: Sun, 12 Feb 2023 20:58:33 +0100

Dear Niko,

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



> Am 10.02.2023 um 20:53 schrieb Niko Tyni <>:
> 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:
> Hi, this is about 64-bit time_t, which became supported in glibc 2.34.
>  * 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
> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]