Hi, thank you both for the report and the analysis so far. I managed to reproduce this on a porter box.
Sadly, I haven't found the underlying issue yet, nor do I know why this would appear (only) on powerpc and mips64el. My gut says it's a toolchain issue, as the current version 1:2.66-5 previously built on these architectures (though logs are no longer accessible, the binaries are there). And if it were some more general issue with a toolchain update, we'd see broader failures. I've just uploaded a new version 2.73. This did not fix the issue for me, but being up to date might help down the road. Best, Christian On 2024-12-10 12:38, Chris Hofstaedtler wrote: > Control: retitle -1 libcap2: FTBFS due to test suite failure on mips64el, > powerpc > >> I observed the failure for this package to buildd with powerpc architecture. > > While the failure on powerpc is not release-critical, a similar > failure can be seen on mips64el, which is a release arch. > > https://buildd.debian.org/status/fetch.php?pkg=libcap2&arch=mips64el&ver=1%3A2.66-5%2Bb1&stamp=1730219325&raw=0 On 2024-12-10 17:49, Sean McGovern wrote: > Here's my gdb session > > $ gdb ./libcap/libcap.so > GNU gdb (Debian 15.2-1) 15.2 > <...snipped for brevity...> > Reading symbols from ./libcap/libcap.so... > (gdb) b 42 > Breakpoint 1 at 0xaa70: file execable.c, line 42. > (gdb) r > Starting program: libcap2-2.66/libcap/libcap.so > > Breakpoint 1, __execable_main (argc=1, argv=0x421310) at execable.c:42 > 42 if (argv != NULL && argv[0] != NULL) { > (gdb) info symbol printf > No symbol "printf" in current context. > (gdb) info symbol strcmp > strcmp in section .text of /lib/ld.so.1 > > Surely these symbols should be coming from the .text section of > libcap.so itself? > > The first test for mips64el appears to succeed so I wonder if it is > crashing instead on one of the the strcmp() > calls in SO_MAIN.
