On 12.10.19 06:08, Guillem Jover wrote:
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.
Not yet. But yes, it should be an option for bullseye.
Or is your plan to enable this by default in gcc instead of via flags
passed by dpkg-buildflags?
No, optimization flags are not turned on by default in GCC.
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).
CC'ing Holger here, as this came up with reproducible builds. PGO and
reproducible builds are currently a no-go. So having a nopgo flag would enable
testing reproducible builds without pgo, if they succeed or not.
Mathias
