Build DC++ with LTO enabled
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| DC++ |
New
|
Low
|
Unassigned | ||
Bug Description
Now as we switching to a compiler based on a newer version of gcc than 8.3 (fixes a blocking bug in the LTO process) now LTO is tested with a gcc 11.2 based compiler from MinGW-W64, one which will probably be used for the next DC++ release.
Generally, it is a reading from -flto[=n] to and including -ffat-lto-objects in https:/
The resulting build found to be stable in participating in a recent stress test of various build configurations with ~100k User objects.
However, the following observations can be made:
#1 Building with LTO needs a separate option in the build script to avoid the additional heavy compile/link time increase. LTO should be disabled for building during the ordinary testing/development phase.
#2 Once there is an RC version of DC++, an additional testing of LTO build needed before the actual release.
#3 On Windows to make LTO work liblto_plugin.dll needs to be present in lib\bfd-plugins (it isn't by default) - maybe this can be solved by passing the .dll's default path in the distro by using some switches. Otherwise the build script should ensure that the file is present where it is needed.
#4 Due to https:/
#5 The LTO build process produces a 4 times smaller .pdb file than what is generated for non-LTO builds. Needs to be investigated how this affects crashlog generation.
#6 It looks like an LTO build is more likely trigger an ugly block on modern Windows' SmartScreen feature where the executable is crashing and just getting deleted from the disk upon exectution, without any user interaction or indication of an issue (to be investigated further).
A test of hashing speed of large files with an LTO and a non-LTO build on a modern NVMe SSD storage, where the bottleneck is the CPU not the storage speed, reveals no significant difference when using the two builds.
