Hi, SuSE (Martin) annonunced today that fromw now on SuSE Tumbleweed will ship with LTO-built packages by default [1].
That's a good news, however I have a question wrt how you expect to support LTO in the future. I have been enabling it in my company for just few selected components and I run into trouble several times these last years. In the LTO section you define both a major version and a minor version, however changing any of them will result in LTO build to fail if all binaries involved in the link don't strictly have the exact same version. Recently in gcc 9 we went from version 8.0 to 8.1. In the past in gcc 8 I recall I also hit a problem when it went from 7.0 to 7.1. In my case, it meant recompiling a set of let's say 100 open source libraries, and around 30 different proprietary libraries (we use static linking, that's why all libs have to be rebuilt each time we upgrade gcc to the next minor version). This is still bearable at my level, I don't have too many dependencies. However at scale, I think this can become a problem. What will happen when in gcc 9.3 we change the version to 8.2 ? Will Tumbleweed recompile 100% of the static libraris it ships ? What about all users of Tumbleweed having their own private libs with LTO as well ? In my company, I don't advocate LTO at scale (yet) because of this problem in particular: re-building everything when we release a toolchain with an updated gcc would be too complex. I am totally fine with having the major version mismatch as a showstopper for the link. People will usually not combine a gcc 8 built binary with a gcc 9 one. However if we have made a distinction with major vs minor, is it possible to adopt a backward compatible policy in the minor version ? Let's say I have a shiny new gcc 9, it can combine both LTO binaries of version 8.0 and 8.1. Maybe it can emit a warning saying it will work in degraded mode, but at least allow the build to go on. If having format backward compatible constraints is too hard inside a given major gcc release, may we can consider another alternative to failure. If fat objects were used, and if really the two minor versions are really incompatible, maybe we can fallback on the non-LTO part for the old library and still the link will be successful (but not as optimized as we would like too, most likely warnings will notify about that). I have no idea of the LTO format and if indeed it can easily be updated in a backward compatible way. But I would say it would be nice if it could, and would allow adoption for projects spread on many teams depending on each others and unable to re-build everything at each toolchain update. Cheers, Romain [1] https://lists.opensuse.org/opensuse-factory/2019-07/msg00240.html
