Bug#1112274: trilinos: FTBFS on arm64: collect2: fatal error: ld terminated with signal 6 [Aborted]
Adrian Bunk
bunk at debian.org
Wed Nov 26 06:10:58 GMT 2025
On Tue, Nov 25, 2025 at 03:41:38PM -0100, Graham Inggs wrote:
> Hi Adrian
Hi Graham,
> Thanks for digging into this!
>
> On Mon, 24 Nov 2025 at 03:22, Adrian Bunk <bunk at debian.org> wrote:
> > Already 16.1.0-1 did put mold in CXXFLAGS instead of LDFLAGS (using
> > LDFLAGS seems to work), and this removed the -O2 resulting in building
> > without optimization - which made the build faster.
>
> So mold does not really speed things up?
> Rather, the speed up is due to the accidental removal of the optimization flags?
yes.
> > I would have a tendency to revert the mold change and instead do
> > optimize=-lto, but whether the latter actually solves the problem
> > for Ubuntu is unproven.
>
> Do you mean reverting to the packaging state of 16.1.0-2?
Yes.
> If so, I am in favour. The Ubuntu issues can be fixed in Ubuntu.
>
> What about lowering optimization for riscv64? Or just not building
> there until the hardware is able to cope?
>...
I would rather try to avoid lowering optimization, and -O0 of huge C++
code would strike me as particularly bad.
Creating debug info is actually confirmed to be expensive for C++ code,
and GCC 15 on riscv64 even is significantly slower on that than GCC 14.[1]
For siconos (#1121341) the following brought the compilation of the
problematic file from timeout after 12 hours on the buildd down to
~ 2 hours for me:
ifneq (,$(filter $(DEB_HOST_ARCH), riscv64))
export DEB_CXXFLAGS_MAINT_APPEND += -g1
endif
I would guess that for trilinos this would get the compile time
from 11 days back down to ~ 3 days (untested).
> Regards
> Graham
>...
cu
Adrian
[1] https://lists.debian.org/debian-riscv/2025/09/msg00019.html
More information about the debian-science-maintainers
mailing list