> `%remove_optflags 'undesirable'`
> `%replace_optflags 'oldval' 'newval'`
Then we can have just the simple one. Following works for me:
```
$ rpm --define "%optflags -flto=auto -O2" --define "%replace_optflags() %global
optflags %(echo %optflags | sed s/%{?1}/%{?2}/)" --eval '%replace_optflags
Conan-Kudo approved 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/813#pullrequestreview-274314596___
Should be ok -- we've had -flto and friends on regular %{optflags} forever
(using %global optflags %{optflags} -fno-lto to override where necessary).
The only thing I could foresee breaking (not for OMV) is if someone relies on
_lto_cflags to support different compilers that don't even use
Thank you!
Just to be clear, I did my research of [RFC
2440](https://www.ietf.org/rfc/rfc2440.txt) regarding `` or `` at
`EOF` or at the end of the header, found no restriction or violation. I would
appreciate pointers to anything I might have missed.
--
You are receiving this because you
I can imagine 2 operations:
`%remove_optflags 'undesirable'`
`%replace_optflags 'oldval' 'newval'`
Which would cover your usecases (because appendif is mostly replace if you also
add the oldval to newval)
--
You are receiving this because you are subscribed to this thread.
Reply to this email
Question is how much pain it would be to create the flagomatic eclass in m4
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
and @DimStar77
--
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/814#issuecomment-520847014___
Rpm-maint mailing list
Adding @scarabeusiv
--
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/814#issuecomment-520846697___
Rpm-maint mailing list
As the follow up of https://github.com/rpm-software-management/rpm/pull/813
I would like to have rpm macros that will do operations on `%optflags`:
Example:
- `%filter-out-optflags '-flto=auto'`
- `%append-if-to-optflags '-flto=auto' -ffat-lto-objects`
I found the example how currently we do it
@berolinux Would this have a negative impact for OMV's usage of clang and
leveraging LTO?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Oh, you beat me to it. This lacks the rationale for the removal and misses a
reference to the macro in macros.in, lets go with #813 instead, but thanks
anyway.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Closed #812.
--
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/812#event-2553405175___
Rpm-maint mailing list
This was only added in commit 2bb7b0cf066c97a9d92eb0bf59618896000cb29d,
but turns out that this kind of usage is bad for build reproducability
because the system-specific CPU count gets recorded RPMTAG_OPTFLAGS
and the resulting binaries too (depending on gcc flags).
In addition, gcc upstream has
> 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
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/812
-- Commit Summary --
* Remove %_lto_cflags.
-- File Changes --
M platform.in (3)
-- Patch Links --
https://github.com/rpm-software-management/rpm/pull/812.patch
Merged #800 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/800#event-2553359725___
Rpm-maint mailing list
pmatilai approved this pull request.
The RFC might have something to say about that newline but then, be liberal in
what you accept etc.
I suppose it's okay, thanks for the patch!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
Merged #767 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/767#event-2553340492___
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:
The change might be fine as such, but the summary is unreadable and overall the
message largely fails to explain *why* should one syntax be preferred over
another one. "Because covscan" is not a proper reason.
test(1) man page gives a clue:
```
NOTE: Binary -a and -o are inherently ambiguous.
> 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:
While rpm -V and -q from rpmdb do verify existing signatures on rpmdb walk,
this is largely useless as an attacker with sufficient permissions can modify
the signature tags in rpmdb headers to make a package appear unsigned, after
which it can be freely modified further without rpm seeing
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:
36 matches
Mail list logo
