[0.8.28] Build error apparently caused by LTO having become the default in newest GCC (maybe?)

[c260fg]

Description

After having finally have made the build process which links against system libraries instead than the vendored ones work again by backporting a clonker fix on our 0.8.28.x Solidity stable branch, I've been able to get that probably the reason the build stuck for hours up to timeout (and so also ending all the CI minutes available on our gitlab namespace, which currently causes us quite a big headache) it may have been the deprecation of the USE_LD_GOLD switch, as I am now getting instead the following failure message (thanks god after only 11 minutes), which maybe disabled LTO and which with it enabled seems to cause the build machine to go out of memory.

[100%] Built target yul-phaser
Assembler messages:
{standard input}:7712: Warning: end of file not at end of a line; newline inserted
{standard input}: Error: open CFI at the end of file; missing .cfi_endproc directive
g++: fatal error: Killed signal terminated program lto1
compilation terminated.
make[3]: *** [/tmp/cc61mqWQ.mk:246: /tmp/cciGiqbr.ltrans122.ltrans.o] Error 1
make[3]: *** Waiting for unfinished jobs....
lto-wrapper: fatal error: make returned 2 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status

So, before diving into the commit history to look at how to restore the old behaviour, I would be very glad if somebody could quickly point me to the correct commit I have to look at.

As of right now, I am currently trying to look if adding the !lto option to the PKGBUILD, the -ffat-lto-objects to CXXFLAGS and adding a swap file to the CI machine through the CI file will manage to fix the issue.

Environment

• Compiler version: GCC 15.2.1
• Operating system: DogeOS GNU base

Steps to Reproduce

The Ur build recipe (a PKGBUILD) is located at themartiancompany/solidity0.8.28-ur.

[c260fg]

Ok so I have good news!

While the swap file activation apparently fails because probably the CI Docker container is not allowed to add a swap file, reducing the size of the ramdisk on which the build happens (see the CI file on the universal recipe repo) so to leave 4GB of RAM and explicitly disabling LTO with the !lto in the Ur recipe (and more generally with the -fno-lto) switch managed to have the build successfully complete.

So for me the issue can actually be closed and right now I'm keeping it open only so to let you ponder if it may be appropriate to specify in the hardware build requirements (which I've never read eh) that one must have at least 4GB of RAM+swap in order to build Soliidity and that compiling with LTO enabled greatly increases the needed amount of memory.

Also same as @theamericanaccount in the linked issue I'd like to report The Martian Company must maintain stable branches for each Solidity release in order to build the EVMFS, Git on Ethereum, OpenPGP on Ethereum, the EVM Contracts Source Index, etc. (the list is becoming quite long you know) on DogeOS, so that it now it could make sense to include that information somewhere in the documentation because as it already became apparent it's starting to take quite a large amount of patches to keep building old Solidity versions on modern system, so hindering the ability of distribution maintainers to include them in their repositories and so to build all the software which depends on them, from TMC programs to way more popular ones such as Uniswap clients (V2 depends on 0.5.16!) and others.