Thanks. Maybe I can get the build to dump tests/test-suite.log on failure to make things easier in the future. I'll look into that.

Wild speculation: The "bad files" test succeeded, since it only tests known broken input files that should be rejected. All other tests failed, either because the PNG loader is broken, or the new Smolscale code I imported has an arch-specific issue (most likely).

Thanks. Maybe I can get the build to dump tests/test-suite.log on failure to make things easier in the future. I'll look into that.

Maybe something like configure --verbose-test?

Wild speculation: The "bad files" test succeeded, since it only tests known broken input files that should be rejected. All other tests failed, either because the PNG loader is broken, or the new Smolscale code I imported has an arch-specific issue (most likely).

Yes. You can click the old link on our buildd page. The sparc64 build failure is in fact a regression. The new code added between 1.12.4 and 1.14.0 is highly likely the root of the issue.

Just added commit c4695d4 - it will dump logs of failed tests to console.

I suspect it's an alignment issue, and the logs will probably just say "Bus error". So no need to hurry, I can probably trigger the issue here. I don't have sparc64, but I have an extremely old arm board and a riscv one here somewhere.

The tests succeed on armv6l and riscv64. Looking closer at the Debian sparc64 log, it seems like the successful test is the ChafaTermInfo standalone API test, but all the tests that involve running the chafa CLI tool fail. So maybe the bug happens earlier in the CLI tool run, and not in Smolscale after all. But it's hard to tell:

PASS: term-info-test
FAIL: chafa-tool-bad-test.sh
FAIL: chafa-tool-cmode-test.sh
FAIL: chafa-tool-format-test.sh
FAIL: chafa-tool-loader-test.sh
FAIL: chafa-tool-options-test.sh
FAIL: chafa-tool-pipe-test.sh

It seems DDs have access to sparc64 porterbox https://db.debian.org/machines.cgi . I'll rebuild with that patch and get back. May lag a little bit as I'm busy with paper rebuttal recently.

I wasn't able to get the Debian sparc64 port working in qemu, but managed with NetBSD. It passes the tests and runs fine there from what I can tell. Maybe something going on with the Debian builds?

(Had to build it with clang, since lodepng.c made gcc crash).