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

[Adrian Bunk]

On Sat, Nov 22, 2025 at 07:53:42PM -0100, Graham Inggs wrote:
> Hi Adrian

Hi Graham,

> On Sat, 22 Nov 2025 at 19:22, Adrian Bunk <bunk at debian.org> wrote:
> > 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]
> 
> Please feel free to upload as you see fit.  You can commit to salsa
> and/or NMU, whichever you prefer.

done (NMU and git), but:

On Sat, Nov 22, 2025 at 10:22:36PM +0200, Adrian Bunk wrote:
> On Sat, Nov 22, 2025 at 11:03:24AM -0100, Graham Inggs wrote:
>...
> > [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]

I should really have double-checked that before uploading, because what 
is actually happening is rather unwanted - and I finally understood it 
after remembering:

On Fri, Sep 05, 2025 at 05:42:31PM +0200, Emanuele Rocca wrote:
>... 
> This unsets all CXXFLAGS!
>...

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.

Emanuele, did you use a version built without optimization when 
discovering that -ffunction-sections helps?
Without -ffunction-sections it builds for me when optimization is not 
disabled, mold/arm64 seems to fail on the unoptimized code - which it 
shouldn't but that's not such a big issue.

Regarding 16.1.0-2ubuntu1, that fixed the Ubuntu build with the same 
"without optimization". Looking at the build logs of 16.1.0-2 in Ubuntu
it surprisingly failed due to lack of disk space (and not lack or RAM).
Maybe LTO requires more diskspace with -O2 than with -O0, and in that
case disabling LTO would help Ubuntu.

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.

I remembered that we also have a failure with mold on arm64 in deal.ii, 
and that is a variant of the same problem:
Manually reverting [1] fixes the deal.ii/arm64 build with mold,
but reverting mold usage might be the easiest fix.
Using -DCMAKE_BUILD_TYPE=Release for not additionally building and 
shipping a half GB debug version of the library would be another option.

> Regards
> Graham

cu
Adrian

[1] https://github.com/dealii/dealii/commit/b8d1c41fc07b9f0a759d60956613c27d753f0960