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