> I can see -flto=auto being useful for the average upstream makefile defaults
> but I'm not convinced this is the right thing to do in rpm context: we'd want
> our parallel activities controlled via the same central tunables
> ($RPM_BUILD_NCPUS / %{_smp_ncpus_max}).
Which is way you want to controll a build system (make). Note that `-flto=N` is
used for parallel linking phase and with the new option `-flto=auto` we can
respect make's jobserver parallelism level
and communication with it. And as a fallback we want to make linking as
parallel as possible. That's what we do in openSUSE right now.
> If LTO falls back to detecting number of cores on its own, that goal was
> missed.
>
> Is there a summary of the gcc community reasoning someplace or can you
> provide one?
The main problem is that we see a lot of differences due to package builds with
different `-flto=N` values. That's because some packages embed options (for
`--help`) option. And mainly we want to have a bitwise identical `rpm` for
reproducible builds. That's why we want to leave `-flto=N` option.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/809#issuecomment-520392154
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
