Post by Guillem Jover
Control: tag -1 - patch + moreinfo
Control: retitle -1 dpkg-buildflags: Add support for an optimize area for things like LTO
Post by Matthias Klose
Please add an optimization area (opt, optimization) for extra optimizations
like lto (link time optimization) and pgo (profile guided optimization).
lto can be directly translated into compiler flags, as seen in the attached
patch, assuming that no lto across package boundaries is done (ensured by
the debhelper patch in #939656). The patch assumes that just nolto can be
used to disable lto until an area is introduced in dpkg.
Some upstream packages also provide build support for lto builds, so for
these an option should be given to disable the addition to the compiler
flags (like the nolto in the proposed patch).
I take you are requesting both adding this and also enabling LTO by
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
Post by Guillem Jover
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.
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.
It's now on by default in Suse and Fedora, and I'm evaluating a complete Ubuntu
test rebuild with lto on. So there are a few things which need to be manually
disabled, so I'm asking about the naming first. I don't think that lto by
default is out of scope for bullseye.
Post by Guillem Jover Post by Matthias Klose
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
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.