As an upstream developer I often struggle with replicating issues seen with a fedora package build because of missing warning, hardening flags or annobin injection. It would be really convenient if redhat-rpm-config would provide a pkgconfig file with the default build flags to use on the system as if building an rpm package. If the flags would also be available in an system-defaults.pc then it becomes easier for upstream projects or a CI system to do builds as Fedora would do them. Then you could simply configure CFLAGS=$(pkgconf --cflags system-default) I am suggesting the name system-defaults.pc so it is actually distro independent (hopefully other distros would provide a similarly named pkgconfig file).
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.