No, just the merged library. Would be nice to use it in externals too, but that would probably require fiddling with the
various external build systems to pass in the necessary flags and workaround the consequent bugs.
Would it be simpler if we didn't have a separate gb_LTOFLAGS but simply added the LTO flags into $CC and $CXX (or $CFLAGS)?
I think that at least with Apple's linker, using "Thin" LTO (https://blog.llvm.org/posts/2016-06-21-thinlto-scalable-and-incremental-lto/ ) is supposed to be quite transparent. You just compile all (or even just a subset) of your source code with -flto=thin, and the linker will notice and apply LTO to those objects. You will just notice the increased link time, (Probably offset by somewhat decreased compile time, though.)
The -flto=thin mode is available also in Clang on LInux, but, as you say, then you need to know that the linker that gets used also supports it.
Probably only worth doing for things that show up in profiles (icu comes to mind)
Probably nss? The crypto stuff there likely shows up in a profile if you load or save password-protected (i.e. encrypted) ODF documents.
--tml
_______________________________________________ LibreOffice mailing list LibreOffice@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/libreoffice
