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

[Adrian Bunk]

On Sat, Nov 22, 2025 at 11:03:24AM -0100, Graham Inggs wrote:
> Emanuele wrote on irc that it may be possible to use mold on arm64.
> Maybe the same workaround could be used for other architectures?

The mold upstream maintainer is active and responsive with fixing bugs,
an upstream bug report would be the proper way forward for architecture 
issues.

I have an item somewhere on my (long) TODO list that I want to check 
using mold for more packages, and into what architecture issues this 
might run. My impression so far is that mold might not yet be mature 
enough for widespread usage.

My short-term aim is to shorten the ongoing numerical stack transition 
by a week on riscv64, since the latest build of trilinos took 11 days.[1]

> However, I am hesitant to switch to mold in Debian now, as mold has
> some RC bugs that would make trilinos eligible for removal from
> testing.

I've just uploaded a fix for that.

Mid-term using mold likely runs into #1114210, but I am optimistic that 
upstream will fix this in the foreseeable future.

> For what it's worth, trilinos builds fine in Ubuntu on arm64 (without
> the workaround), and using mold there is needed to avoid running out
> of space on their buildds.

Ubuntu is still using mold 2.37.1+dfsg-1 due to #1119807,
it is possible that this is a recent arm64 regression in mold.

> [00:00:00] - {Day changed to Monday, 15 September 2025}
> 
> [09:53:48] <ema> ginggs: while I have your ear, it seems that building
> trilinos with -ffunction-sections is an effective workaround for
> #1112274
> 
> [09:53:50] [zwiebelbot] Debian#1112274: trilinos: FTBFS on arm64:
> collect2: fatal error: ld terminated with signal 6 [Aborted] -
> https://bugs.debian.org/1112274
> 
> [09:54:03] <ema> apparently having smaller .text sections helps mold
> not falling on its face
> 
> [09:55:45] <ema> I tried rebuilding both without mold and and with
> mold (and -ffunction-sections), didn't see any performance improvement
> really
> 
> [09:56:43] <ema> actually a slight degradation: 01:59:40 with mold and
> 01:52:19 without
>...

Perhaps that's due to -ffunction-sections?

A factor of 3-5 in the build time seems normal when comparing 16.1.0-1
with 16.1.0-2 on the other architectures:
https://buildd.debian.org/status/logs.php?pkg=trilinos&arch=amd64
https://buildd.debian.org/status/logs.php?pkg=trilinos&arch=ppc64el
https://buildd.debian.org/status/logs.php?pkg=trilinos&arch=s390x
https://buildd.debian.org/status/logs.php?pkg=trilinos&arch=sparc64

My "This got the build time on riscv64 down from 1 week to 1 day with 
GCC 14" was also something I did measure back then.[2]

Buildtime of trilinos on arm64 is not a huge issue even though it's
~ 18 hours on some buildds, your Ubuntu change plus -ffunction-sections
on arm64 might be a good short-term solution?

cu
Adrian

[1] GCC 15 brings additional build time regression here:
    https://lists.debian.org/debian-riscv/2025/09/msg00019.html
[2] I don't remember exact numbers, but with GCC 14 the build finished
    in < 1 day on the porterbox (same hardware as the buildds)