On February 5, 2018 12:26:58 PM GMT+01:00, Allan Sandfeld Jensen <li...@carewolf.com> wrote: >Hello GCC > >In trying to make it possible to use LTO for distro-builds of Qt, I >have again >hit the problem of static libraries. In Qt in general we for LTO rely >on a >library boundary, where LTO gets resolved when generating the library >but no >LTO-symbols are exported in the shared library. This ensure the library >has a >well defined binary compatible interface and gets LTO optimizations >within >each library. For some private libraries we use static libraries >however, >because we don't need binary compatibility, but though we don't need BC > >between Qt versions, the libraries should still be linkable with >different gcc >versions (and with different compilers). However when LTO is enabled >the >static libraries will contain definitions that depend on a single gcc >version >making it unsuitable for distribution. > >One solution is to enable fat-lto object files for static libraries but >that >is both a waste of space and compile time, and disables any LTO >optimization >within the library. Ideally I would like to have the static library do >LTO >optimizations internally just like a shared library, but then exported >as >static library. > >I suspect this is more of gcc task than ar/ld task, as it basically >boils down >to gcc doing for a static library what it does for shared library, but >maybe >export the result as a single combined .o file, that can then be ar'ed >into a >compatible static library. > >Is this possible?
Hmm. I think you could partially link the static archive contents into a single relocatable object. Or we could add a mode where you do a 1to1 LTO link of the objects and stop at the ltrans object files. You could stuff those into an archive again. I'm not sure how far Honza got partial LTO linking to work? Richard. >Best regards >'Allan Jensen
