On Thu, 2019-10-10 at 10:39:23 +0200, Matthias Klose wrote: > On 09.10.19 20:28, Guillem Jover wrote: > > I take you are requesting both adding this and also enabling LTO by > > default? > > the infrastructure should provide both, having the option to enable it by a > flag when it's not the default, and to disable it by default, when it's > enabled by default.
This is something provided for all supported features, but this does not answer whether you are requesting this to be the default or not. Or is your plan to enable this by default in gcc instead of via flags passed by dpkg-buildflags? > > I'm fine with the former (even implementing that myself), but the latter > > would need to go through [Q] first. And I see this can cause breakage [O] > > according to the OpenSUSE people. > > > > [Q] > > <https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Can_we_add_support_for_new_default_build_flags_to_dpkg-buildflags.3F> > > [O] > > <https://hubicka.blogspot.com/2019/05/gcc-9-link-time-and-inter-procedural.html> > > well, yes, it breaks a few packages, more than a handful, but not the whole > archive, and you can name these packages. The question for now is how to > name that option, and how to disable that on a per package basis. And we > probably want to enable that for a subset of architectures first, which have > been test built. So the first thing is the name, so people can disable lto, > before we even consider making it the default. If you are suggesting repeating the same disaster that we have with pie, with the default set by gcc being arch opt-in, then I'm honestly less than interested in doing the same here, and I'd consider this a direct wontfix. :/ > > > pgo doesn't directly translate into compiler flags, but almost always > > > requires upstream support in the build system. pgo usually is enabled by > > > some configure options which are specific to the upstream build. pgo > > > usually requires running a profiling task, so this optimization probably > > > should be disabled for cross builds, otoh, the cross build then is > > > different > > > to the native build (although it should create a functional identical > > > package). > > > > I don't see how dpkg can support PGO, so I'm excluding that from this > > request, as it seems this would be pretty much unactionable. > > The only thing it would do is to provide a common interface to > enable/disable it, not an implementation. Ok, I guess, given that using unknown features for known areas emits warnings (even though it seems weird and unexpected to support a feature for which dpkg-buildflags will never be able to emit flags for, and some other name could be used for this, but consistency would be nice). Regards, Guillem
