> 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
> 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
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
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
> 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)
> 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
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 ,
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.
Since nobody's objecting...
--
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/806#issuecomment-520315611___
Rpm-maint mailing list
Merged #806 into master.
--
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/806#event-2549247535___
Rpm-maint mailing list
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:
11 matches
Mail list logo
