Re: [Rpm-maint] [rpm-software-management/rpm] Use -flto=auto as a default for _lto_cflags. (#809)
> Ah... now I get it. I somehow got the impression that it was the linking that > produced different results with different number of cpus (as often happens > with parallel compression etc) That's good we understand each other. No, our parallel linking in LTO is stable. Right now we divide the job to `128` parts and then these parts are processed in parallel by multiple processes. -- 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-520399131___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Use -flto=auto as a default for _lto_cflags. (#809)
> Then rpm -qp --qf "%{OPTFLAGS}" $rpm will show you the -flto=8 and that's the
> problem for reproducibility.
Ah... now I get it. I somehow got the impression that it was the linking that
produced different results with different number of cpus (as often happens with
parallel compression etc)
--
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-520398550___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Use -flto=auto as a default for _lto_cflags. (#809)
> Maybe I'm missing something fundamental here, but I don't understand how is
> -flto=auto supposed to help with making builds more reproducable.
Because if you are given a builder with 8 cores:
```
[ 40s] + export 'CFLAGS=-O2 -Wall -D_FORTIFY_SOURCE=2
-fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables
-fstack-clash-protection -Werror=return-type -flto=8 -g'
```
Then `rpm -qp --qf "%{OPTFLAGS}" $rpm` will show you the `-flto=8` and that's
the problem for reproducibility.
> In rpm context, the number of cpus make uses is typically set by rpm (whether
> configuration or "all available"), and if you let it fall back to "as many as
> possible" then it's just as system dependent as the current rpm set method,
> no?
Yes, except we can communicate with `make` job server and run tasks
dynamically. And if not, then we'll do the same. Except we'll not have issues
with reproducibility.
--
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-520397317___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Use -flto=auto as a default for _lto_cflags. (#809)
Maybe I'm missing something fundamental here, but I don't understand how is -flto=auto supposed to help with making builds more reproducable. In rpm context, the number of cpus make uses is typically set by rpm (whether configuration or "all available"), and if you let it fall back to "as many as possible" then it's just as system dependent as the current rpm set method, no? -- 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-520395581___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Use -flto=auto as a default for _lto_cflags. (#809)
> 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
Re: [Rpm-maint] [rpm-software-management/rpm] Use -flto=auto as a default for _lto_cflags. (#809)
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}). 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?
--
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-520390459___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Use -flto=auto as a default for _lto_cflags. (#809)
Hope @pmatilai can help me with this pull request? -- 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-520366815___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Addition of 'V=1' to %make_build broke a package (#798)
Meh, wrong button... Closing as per above. -- 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/issues/798#issuecomment-520326737___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Addition of 'V=1' to %make_build broke a package (#798)
Fixed in commit c7e0b61c05878868300653d5892425c6c41fdba0 -- 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/issues/798#issuecomment-520326623___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Addition of 'V=1' to %make_build broke a package (#798)
Closed #798. -- 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/issues/798#event-2549342624___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Support triple operator for conditional shortcut (#115) (#746)
As mentioned in the ticket (#115), I want to see a plan for a syntax that allows for generic condition instead of just existence test before proceeding. Also mentioned in the ticket, the syntax has other issues too. Lets discuss those in the ticket to keep it all in one place. @pavlinamv , while it's perfectly fine to remove "blocked" flag set by yourself, leave it alone when others set it. It's a warning flag to others to not merge even if other indicators appear in the green - for example here we're only discussing the syntax being introduced, and we're not ready for merge even if the code were technically acceptable and passing tests. Finally, this has conflicts now and should be rebased, but that can wait until the syntax side is settled. -- 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/746#issuecomment-520325143___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Triple operator for conditional shortcut (#115)
Another thing is that this syntax makes it impossible to have colons (':') in
the output (eg '%{!?foo::}'), which is a limitation the original syntax doesn't
have'. It obviously has it's own set of limitations and quirks...
--
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/issues/115#issuecomment-520321390___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
