Bug#1112274: trilinos: FTBFS on arm64: collect2: fatal error: ld terminated with signal 6 [Aborted]

Matthias Maier tamiko+debian at 43-1.org
Wed Nov 26 18:14:14 GMT 2025


Dear all,

Apologies that I caused all this mess by accidentally overriding CXX
flags.


On Wed, Nov 26, 2025, at 00:10 CST, Adrian Bunk <bunk at debian.org> wrote:

>> > 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 agree that the absence of optimization flags will speed up the
compilation process.

But, the whole reason why we switched linkage over to mold is that it
improved the link time for larg(er) shared library objects significantly
as opposed to ld.bfd - and this helped a lot with build times
(particularly for deal.ii) on some of the build daemons.

I am happy to quantify that for trilinos as well but here is a very
quick comparison (bfd 2.45.0 vs mold 2.40.4):

Link times for a small executable linking against Trilinos and a metric
ton of other libraries:

  -fuse-ld=mold:                 0.03s user 0.02s system 10% cpu  0.488 total
  -fuse-ld=mold -Wl,--nothreads: 0.05s user 0.02s system  7% cpu  1.024 total
  -fuse-ld=bfd:                  9.80s user 4.31s system 99% cpu 14.253 total

And for linking a very large shared library library (deal.ii):

  -fuse-ld=mold:                 0.05s user 0.04s system 15% cpu 0.534 total
  -fuse-ld=mold -Wl,--nothreads: 0.05s user 0.04s system  7% cpu 1.220 total
  -fuse-ld=bfd:                  2.52s user 1.38s system 99% cpu 3.915 total

(I have to say I am impressed by how much faster ld.bfd has become
compared to the last time I quantified this.)

The speed improvement for the over 60 shared libraries for Trilinos will
range somewhere in between.

Best,
Matthias



More information about the debian-science-maintainers mailing list