Bug 1880641

You can query these from rpm, some examples:

[pmatilai🎩︎lumikko ~]$ rpm --eval "%{build_cflags}"
-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
[pmatilai🎩︎lumikko ~]$ rpm --target i686 --eval "%{build_cflags}"
-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m32 -march=i686 -mtune=generic -msse2 -mfpmath=sse -mstackrealign -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
[pmatilai🎩︎lumikko ~]$ rpm --target i686 --undefine "_hardened_build" --eval "%{build_cflags}"
-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches  -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m32 -march=i686 -mtune=generic -msse2 -mfpmath=sse -mstackrealign -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
[pmatilai🎩︎lumikko ~]$ rpm --target ppc64le --eval "%{build_ldflags}"
-Wl,-z,relro -Wl,--as-needed  -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld

In principle it's a nice idea, developers are likely to be more acquainted with pkgconf than rpm (witness this bug:)
There'd probably need to be multiple such files to account for major configurables (such as hardening). A bigger obstacle might be per-architecture flags, which need to be handled somehow - we could put them into separate files too, but then the number with combinations starts getting unwieldy.

(In reply to Panu Matilainen from comment #1)
> You can query these from rpm, some examples:
> 
> [pmatilai🎩︎lumikko ~]$ rpm --eval "%{build_cflags}" [...]

Yeah.

> There'd probably need to be multiple such files to account for major
> configurables (such as hardening). 

I think the attraction of a single .pc would be to match the "default"
case used in the distro.  If an ISV/package wants to micromanage e.g.
hardening, they could do so with or without the .pc originated cflags.

> A bigger obstacle might be per-architecture flags, which need to be
> handled somehow - we could put them into separate files too, but then
> the number with combinations starts getting unwieldy.

Could the .pc files be created during %post, to mechanize it fully?

We could start with just a native one, and if there is interest, maybe
generate a suite of arch-specific ones?

This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle.
Changing version to 34.

This message is a reminder that Fedora Linux 34 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '34'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 34 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

This would still be a useful feature.