Bug#1082747: cod-tools: FTBFS (only) on riscv64

gregor herrmann <[email protected]>
Newsgroups gmane.linux.debian.devel.perl
Message-ID <172727822740.26662.11249122923181439023.reportbug__20279.8578118504$1727278411$gmane$org@jadzia.comodo.priv.at>
Source: cod-tools
Version: 3.10.0+dfsg-1.1
Severity: serious
Tags: help ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: [email protected], [email protected]
User: [email protected]
Usertags: perl-5.40-transition

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

I noticed that cod-tools 3.10.0+dfsg-1.1 fails to build but only on
riscv64:

https://buildd.debian.org/status/package.php?p=cod-tools
https://buildd.debian.org/status/logs.php?pkg=cod-tools

I care about this issue because 1) I uploaded the -1.1 NMU, and 2)
this will get in the way of the Perl 5.40 transition (#1082293),
which was the reason for the NMU in the first place, as it blocks the
migration of cod-tools.

Observations and thoughts:
* -1 built everywhere, including riscv64
* -1.1 still builds everywhere, except for riscv64
* I don't think the changes from the NMU (Niko's Perl exporter()
  patch) are related
* The build on riscv64 failed 4 times, so not a
  parallelization/timing issue probably (and d/rules uses
  --no-parallel)

On riscv64 the build fails with

#v+
tools/help2man scripts/utf8-to-cif --bugs-email [email protected] > doc/man/utf8-to-cif.1
make[1]: *** No rule to make target 'doc/man/cif_list_tags.1', needed by 'man'.  Stop.
make[1]: Leaving directory '/<<PKGBUILDDIR>>'
v-

On amd64 we see:

#v+
tools/help2man scripts/utf8-to-cif --bugs-email [email protected] > doc/man/utf8-to-cif.1
src/components/codcif/cif_list_tags --help | tools/help2man --stdin --name cif_list_tags --bugs-email [email protected] > doc/man/cif_list_tags.1
src/components/codcif/cifparse --help | tools/help2man --stdin --name cifparse --bugs-email [email protected] > doc/man/cifparse.1
src/components/codcif/cifvalues --help | tools/help2man --stdin --name cifvalues --bugs-email [email protected] > doc/man/cifvalues.1
make[1]: Leaving directory '/<<PKGBUILDDIR>>'
#v-

So it looks like src/components/codcif/cif_list_tags exists on amd64
et al., but not in riscv64.
  
The compliation step on amd64:

#v+
gcc -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -Wall -Wsign-compare -g -O3 -funroll-loops -fomit-frame-pointer -foptimize-register-move -DYYDEBUG=1 -D_YACC_ -I. -I../../externals/cexceptions -I../../externals/getoptions -fPIC -DSVN_VERSION="\"10068\""  -Wl,-z,relro -Wl,-z,now -o cif_list_tags programs/cif_list_tags.c obj/cif2_grammar.tab.o obj/cif_grammar.tab.o lib/libcodcif.a ../../externals/cexceptions/lib/libcexceptions.a ../../externals/getoptions/lib/libgetoptions.a version.h -lm
#v-

and on riscv64:

#v+
gcc -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wsign-compare -g -O3 -funroll-loops -fomit-frame-pointer -foptimize-register-move -DYYDEBUG=1 -D_YACC_ -I. -I../../externals/cexceptions -I../../externals/getoptions -fPIC -DSVN_VERSION="\"10068\""  -Wl,-z,relro -Wl,-z,now -o cif_list_tags programs/cif_list_tags.c obj/cif2_grammar.tab.o obj/cif_grammar.tab.o lib/libcodcif.a ../../externals/cexceptions/lib/libcexceptions.a ../../externals/getoptions/lib/libgetoptions.a version.h -lm
#v-


I've been staring at the logs for some time but haven't found out
what's happening here on riscv64; help welcome.


Cheers,
gregor

-----BEGIN PGP SIGNATURE-----

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmb0LJNfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgY+bg//VBndn6WMjaQG2mzNs0JWRp1YyCLO/mj+HfaLfsS4RD7ilmleTDlauHsl
3XEeIjjHyfd8bLQATYujHCsUCUzJHWgcpmdo9Sq//ItoAnYJFFPY8WHCMokCZejb
kOVW32+rgdLfUMkMNVfao0lgAJ6aFmgc69+OKdWOWoCn9Qw6UpRxiBNzUA8g//CC
WIG44ThrWxohW1+OApmGYijtVDCpy3wsO8P2kl+A8Un4YjbnAQ7KwN3n05dTXFr0
9981IevQxIkuuBLynl6WMqCuq/HcY2FTnZRozxrNx7UKbulWy1dsrXkcuWBA3648
eUxGr9WovyfRckLQujji5hqYrjHwm9y3YXaG1u9ORnn4dE41igKk1giBFv7IMOCA
OMxY4G39OPhd7zXtXqVRzMzgU55cIbqhllHYYLb3fnkx5uN2mBjA0q1c9CKyxptx
BujFCUUnO5aCPaXs7Q3AE6P9OzAnLVZvdFzrxuXQxXLnxqrq8xfr0FfCDd0ndEde
DGciUaBfWko5+kbQIDc93VXBikj7tHmpzyxstkYoDvPtS69flfpbHanGcJ/k7F2H
Ko0LljzaVxOftUXCh3ES5Rm/ZUuujjwUVd33a/rkmu1jqPQOZTITywwoXeR2H4cA
Aay1b7KkEDKk7bBFTTX9ufH1qQIbBYHBk5aGLYrlq1r/2r8BWLc=
=C7lE
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.