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

[Andrius Merkys]

Hi,

On 2024-09-25 18:30, gregor herrmann wrote:
> 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)

Thanks a lot for giving this issue a look. I scratched my head a lot on 
this issue this week. What I find even more interesting, is that -1.1 
successfully builds on riscv64 porterbox (ricci.debian.org).

> On riscv64 the build fails with
> 
> #v+
> tools/help2man scripts/utf8-to-cif --bugs-email cod-bugs at ibt.lt > 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 cod-bugs at ibt.lt > doc/man/utf8-to-cif.1
> src/components/codcif/cif_list_tags --help | tools/help2man --stdin --name cif_list_tags --bugs-email cod-bugs at ibt.lt > doc/man/cif_list_tags.1
> src/components/codcif/cifparse --help | tools/help2man --stdin --name cifparse --bugs-email cod-bugs at ibt.lt > doc/man/cifparse.1
> src/components/codcif/cifvalues --help | tools/help2man --stdin --name cifvalues --bugs-email cod-bugs at ibt.lt > 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.

This is really strange, because, as you have noticed, 
src/components/codcif/cif_list_tags is successfully built earlier:

> 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.

Same. I wonder if we can ask buildds to test-rebuild -1.

Thanks,
Andrius