FS#69333 - [kodi] build with -DUSE_LTO=$(nproc)
Attached to Project:
Community Packages
Opened by John (graysky) - Friday, 15 January 2021, 09:51 GMT
Last edited by Ike Devolder (BlackEagle) - Saturday, 27 February 2021, 14:13 GMT
Opened by John (graysky) - Friday, 15 January 2021, 09:51 GMT
Last edited by Ike Devolder (BlackEagle) - Saturday, 27 February 2021, 14:13 GMT
|
Details
Building with this switch reduced installed size reported by
pacman vs the identical commit (kodi-x11 from master not
version 18.9 but should give similar results) built without
native LTO enabled is approx 10% smaller:
Total Installed Size: 81.43 MiB Net Upgrade Size: -8.50 MiB In addition to the size savings, in general, there known gains in efficiency and speed in the executables/DSOs compiled with LTO. See the following and some of the links therein: https://fedoraproject.org/wiki/LTOByDefault |
This task depends upon
Closed by Ike Devolder (BlackEagle)
Saturday, 27 February 2021, 14:13 GMT
Reason for closing: Implemented
Additional comments about closing: implemented in upcoming kodi 19
Saturday, 27 February 2021, 14:13 GMT
Reason for closing: Implemented
Additional comments about closing: implemented in upcoming kodi 19
I would guess that LTO does not care how many processes you use to do it... But if it did care then this is completely unacceptable as we would automatically have to reject any suggestion that makes the Reproducible Builds status of a package dependent on the number of cores possessed by the build server.
Which does nothing other than add -flto=2 (or -flto=$(nproc) with your suggestion) and -fno-fat-lto-objects to C/XX FLAGS.
Again, if this is so great then the best place to do it is in makepkg.conf rather than cherry-picking one application to build with LTO using custom code.
Note that I tried building with -flto in my makepkg.conf[1] in a clean chroot, but that ended in errors[2]. Enabling lto via the cmake switch builds successfully but only with the distro default CFLAGS.
1. CFLAGS="-march=x86-64 -O2 -pipe -fno-plt -flto" ; CXXFLAGS="${CFLAGS}"
2. https://gist.github.com/graysky2/951bb3620c8a42782dd238c75ba99dd3
CFLAGS+=" -flto=8 -fno-fat-lto-objects"
CFLAGS="-march=x86-64 -O2 -pipe -fno-plt -fdiagnostics-color -flto=8 -fno-fat-lto-objects"
CXXFLAGS="${CFLAGS}"
LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -flto=8 -fno-fat-lto-objects"
So the internal USE_LTO does something special.
Using DUSE_LTO:BOOL=ON only sets the options for the kodi build itself. You should be able to trigger ffmpeg failing with similar output by adding -flto to *FLAGS.
Edit:
With ffmpeg change --enable-lto to --disable-lto add -flto to * FLAGS.
Poor examples showing
PKGBUILD1.diff enable LTO in ffmpeg's configure
PKGBUILD2.diff disable LTO when build ffmpeg
Edit2:
ffmpeg's configure script disables inline_asm_direct_symbol_refs when using the lto option but not when -flto is used in FLAGS used, passing --disable-x86asm to configure allows building with the -flto in FLAGS.
PKGBUILD2.diff (1.3 KiB)
Not figured out how to fix ffmpeg's configure script to disable inline_asm_direct_symbol_refs when -flto is used in FLAGS.