On Mon, 29 Apr 2019, Martin Liška wrote:
On 4/25/19 9:23 AM, Thorsten Kukuk wrote:
Hi,
On Tue, Apr 23, Martin Liška wrote:
LTO stands for Link Time Optimization and it is a GCC optimization technique that improves speed and reduces size of binaries. According to our measurements, ELF binaries will be about 5% smaller and debug info packages by 15%. Now, there are various interesting packages that have been LTO in Factory right now: libreoffice, MozillaFirefox, python3, gcc9.
If I read that LTO doesn't work with symbol versioning, isn't then introducing LTO contra productive?
No. Right now we're talking about 15-20 packages that use symbol versioning (out of ~3000). Moreover, LTO is the most beneficial for executables of a reasonable size where scope of exported symbols is limited. On the contrary, libraries have a lot of symbols (functions) exported.
Note that we're planning to add support for symber in next GCC release.
IIRC symbol-versioning with -Wl,-map should work just fine, just the glibc way of using toplevel asms does not. Hopefully not too many projects copied that way. For C++ restricting visibility is something that works as well and is similarly useful (just w/o the versions).
We need much more shared libraries with symbol versioning then less or LTO ...
Yes.
I think we need more (C++) shared libraries that make their set of exported symbols explicit. Not sure if we really need more libraries with several variants of the same symbol ;) Richard.
Martin
Thorsten
-- Richard Biener <rguenther@suse.de> SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer, Mary Higgins, Sri Rasiah; HRB 21284 (AG Nürnberg)