Source: libcrypt-gcrypt-perl
Version: 1.26-6
Severity: serious
Tags: trixie sid patch
User: debian-...@lists.debian.org
Usertags: ftbfs-gcc-14

Rebuilding this package on current sid produces an empty package.

The build system has trouble compiling or linking against gcrypt, but
the build does not fail and produces an empty package instead.

  
https://perl.debian.net/rebuild-logs/sid/libcrypt-gcrypt-perl_1.26-6/libcrypt-gcrypt-perl_1.26-6_amd64-2024-08-06T20%3A50%3A39Z.build

  dh build
     dh_update_autotools_config
     dh_autoreconf
     dh_auto_configure
        /usr/bin/perl Makefile.PL INSTALLDIRS=vendor "OPTIMIZE=-g -O2 
-Werror=implicit-function-declaration -ffile-prefix-map=/<<PKGBUILDDIR>>=. 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2" 
"LD=x86_64-linux-gnu-gcc -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
-Wl,-z,relro"
  Can't link/include C library 'gcrypt', aborting.
     create-stamp debian/debhelper-build-stamp

Adding $args{debug}=1; to assert_lib() in inc/Devel/CheckLib.pm
reveals the reason:

  /usr/bin/x86_64-linux-gnu-gcc -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv 
-fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 -fstack-protector-strong -L/usr/local/lib -ldl -lm 
-lpthread -lc -lcrypt assertlib6Oi264pB.c -o assertlib1CazVLAR -L-lgcrypt 
-lgcrypt
  assertlib6Oi264pB.c: In function 'main':
  assertlib6Oi264pB.c:1:22: error: implicit declaration of function 
'gcry_check_version' [-Wimplicit-function-declaration]
      1 | int main(void) { if (gcry_check_version("1.3.0")) return 0; else 
return 1; }
        |                      ^~~~~~~~~~~~~~~~~~
  Can't link/include C library 'gcrypt', aborting.

So this is a GCC 14 related regression and is fixed by including
the gcrypt.h header with the version check. Patch attached.

As for not failing the build, looks like the upstream part of that is
intentional so that CPAN testers don't report failures due to lack of
external libraries. And debhelper / dh presumably sees that running
Makefile.PL doesn't produce a Makefile and assumes that this is not a
standard Perl package after all.

Not sure where that leaves us. Some solutions I can think of:
- patch Makefile.PL to use assert_lib() instead 
- add a check in debian/rules to detect the failure
- call dh explicitly with --buildsystem=perl_makemaker 
- change dh to fail the build if 'perl Makefile.PL' does not produce a Makefile

The last option is the only generic one, but might interfere
with the dh buildsystem automatic detection.
-- 
Niko
From: Niko Tyni <nt...@debian.org>
Date: Tue, 6 Aug 2024 22:08:51 +0100
X-Dgit-Generated: 1.26-6 c705b78053f02909c0db5549b794ad9f9fe10217
Subject: fix build with GCC-14


---

diff --git a/Makefile.PL b/Makefile.PL
index 86de082..0bf1af6 100644
--- a/Makefile.PL
+++ b/Makefile.PL
@@ -41,6 +41,7 @@ if (not $gcrypt_libpath and $] >= 5.006001) {
 # SHA-512)
 check_lib_or_exit(
     function => 'if (gcry_check_version("1.3.0")) return 0; else return 1;',
+    header => [qw(gcrypt.h)],
     lib => [qw(gcrypt)],
     libpath => $gcrypt_libpath
 );

Reply via email to