Due to the organization of our codebase we tend to build and link in a bunch of functions into the binaries that aren't actually used.
I've tried building with -ffunction-sections -fdata-sections -Wl,--gc-sections, and it reduces bitcoind (after stripping) from 7.2 MB to 6.9 MB. The bitcoin-wallet tool goes from 3.5 MB to 1.3 MB.
Any reason why we don't do this? I only find a mention in #4042, but it's not clear how relevant that is to me.
I've got a branch that does link time garbage collection, using pretty much the same flags, and have seen similar binary size savings. If wanted this is probably something we could add to the Guix / Gitian descriptors.
This seems ok, but IIRC if you build with -ffunction-sections and -fdata-sections it mask link errors that would happen without these flags, because the linker won't complain about missing symbols from the sections that are skipped. It might be better to reserve these flags for release builds, otherwise it could be annoying when local builds succeed but appveyor / travis builds have link errors
@ryanofsky That's a good point. Maybe just something to do in Gitian/Guix.
@ryanofsky That's a good point. Maybe just something to do in Gitian/Guix.
Agree. I kind of like this, it's a safer (and link-time much faster) option than going full LTO but still manages to get rid of a lot of cruft in the binary.
I kind of like this, it's a safer (and link-time much faster) option than going full LTO but still manages to get rid of a lot of cruft in the binary.
Just to fully understand the argument: safer than full LTO in what regard?
LTO has historically be a source of bugs in compilers - it's improved a lot of course, and we should evaluate when it's mature enough to enable. But that's a far bigger change than enabling link-time GC.
In addition, experiments in the past have shown that LTO wasn't always a performance gain (it has been a while, the situation may be better now, but even then, maybe we only want it for certain compiler versions etc...).