Hi Nilesh, Nilesh Patra, on 2022-12-04: > There are a bunch of LTO based bugs that have been filed. The packages > that had "real" issues (as in with the code) with LTO have been fixed. > > Now most of what is left is changes in symbols, which fails with > dpkg-gensymbols, > which is just a change with compiler opt, and likely nothing more > and I am not quite thrilled to keep them open until they become RC provided > there > are so many of them. > > Does it make sense to force no-lto in these?
Force no-lto would be the path of least resistance. It won't hurt but won't bring the supposed benefit of the build option. In libraries it might be a shame, as they factor out code used by potentially lots of packages. On the other hand I'm not sure that only private symbols may go away when lto builds are active; I would have to check that by running autopkgtest on reverse dependencies. I remained undecided about adding -fvisibility=hidden, as this might make libraries' symbol tracking overall more manageable, but in some cases, I saw the whole symbols file being emptied, so I assume this is only applicable for upstream sources which provide the appropriate mappings; they would usually include the -fvisibility=hidden flag in their own build options already. But should it give sensible results, it might help with the symbols tracking update caused by lto usage, or even solve it at once. I'm hopeful to be able to take the time to sort one of the libraries during the Advent, to check how reverse dependencies behave when optimisations are applied. Have a nice day, :) -- Étienne Mollier <emoll...@emlwks999.eu> Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/pts/2, please excuse my verbosity.
signature.asc
Description: PGP signature
