> I'd think so.
Good. I've just done that in:
https://github.com/rpm-software-management/rpm/pull/812
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Closed #809.
--
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#event-2553371170___
Rpm-maint mailing list
> So is the conclusion that we want to rip it off?
I'd think so.
On the positive side, it wasn't all for nothing, splitting the number of cpus
-logic out of %_smp_mflags was a very useful thing :)
--
You are receiving this because you are subscribed to this thread.
Reply to this email
> It's also a fine example how basing anything on unreleased development work
> comes back to bite you.
Sure. So is the conclusion that we want to rip it off?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
...and one more note on the subject. The gcc manual says:
```
The important thing to keep in mind is that to enable link-time
optimizations you need to use the GCC driver to perform the link
step. GCC automatically performs link-time optimization if any of
In other news of not-quite-today:
https://www.phoronix.com/scan.php?page=news_item=GCC-10-LTO-flto-Available-Cores
and that has actually been merged into gcc:
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=f12fbeb535f192f742025cc4f9b69a48136730f1
So in the end it's just a matter of passing
With this gcc version business, I'm starting to think this really should not be
in rpm at all. It's not really our job to ponder gcc versions, any more than it
is to know what version of Python is the default or not (referring to another
recent PR, otherwise unrelated)
Lets sleep on it a bit.
> In the meanwhile I learned that flto=auto is not supported by any released
> gcc. We can't really go with such a value in rpm.
Yep, it will be supported first in GCC 10.1 release. For openSUSE, we're using
a patched GCC compiler with the support. So I'm going to push the package to
our `rpm`
In the meanwhile I learned that flto=auto is not supported by any released gcc.
We can't really go with such a value in rpm.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> Sure. It just needs to grow an existence outside GH to be relevant :)
That said I would like to keep the macro in `rpm` as suggested in the patch for
this pull request.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Sure. It just needs to grow an existence outside GH to be relevant :)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@pmatilai we actually do have `rpm-extras` :)
--
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-520766708___
Well, there is *some* value in having such a macro, for example to encourage a
common way to disable (and enable) across different distros. The thing is, it
doesn't really seem to belong to rpm itself, but we lack a better, shared place
to put it in.
--
You are receiving this because you are
> The remaining question I have is whether it actually is worth it to have a
> macro for this at all when we don't default to it at all and even the default
> we ship is static so it's not something rpm would need to (or want to) be
> aware of. Ie, how does this differ from the average other
Bikeshedding the name at this point isn't going to profit anybody.
The remaining question I have is whether it actually is worth it to have a
macro for this at all when we don't default to it at all and even the default
we ship is static so it's not something rpm would need to (or want to) be
> In that case, would not it make sense to rename `%_lto_cflags` to
> `%_lto_flags`?
Well, we already have quite some usage of the name in our distribution. E.g. we
use `%define _lto_cflags %{nil}` to disable LTO for a package.
--
You are receiving this because you are subscribed to this
In that case, would not it make sense to rename `%_lto_cflags` to `%_lto_flags`?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> 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
> 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
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
> 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
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
23 matches
Mail list logo
