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 <[email protected]> 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
