Bug#940571: dpkg-buildflags should support an optimization area for things like lto and pgo

[Matthias Klose]

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