PR#1181: Compiler flags updates - packaging-committee

packaging-committee

#1181 Compiler flags updates

Opened 2 years ago by oturpe. Modified 2 years ago

oturpe/packaging-committee compiler-flags-fixes into master

Otto Urpelainen • 2 years ago

0d74b2b

guidelines/modules/ROOT/pages/RPMMacros.adoc

file modified

+5 -5

		`@@ -108,7 +108,7 @@`
		`\| +%{_buildrootdir}+ \| +%{_topdir}/BUILDROOT+ \|`
		`\|=================================`

		`-`
		`+ [#build-flags-macros-and-variables]`
		`== Macros providing compiler and linker flags`

		`The default build flags for binaries on fedora are also available via macros.`
		`@@ -116,7 +116,7 @@`
		`so it is usually not necessary to use them directly --`
		except, for example, when doing bare bones compilation with `gcc` directly.

		`- The set of flags listed below reflects the current state of fedora 28`
		`+ The set of flags listed below reflects the current state of Fedora 36`
		on a `x86_64` machine, as defined in the file `/usr/lib/rpm/redhat/macros`.

		The `+%{optflags}+` macro contains flags that determine `CFLAGS`, `CXXFLAGS`,
		`@@ -127,14 +127,14 @@`

		`....`
		`$ rpm --eval "%{optflags}"`
		`- -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`
		`+ -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection`
		`....`

		The value of the `LDFLAGS` environment variable set by build systems
		is determined by the `+%{build_ldflags}+` macro:

		`....`
		`- $ rpm -E "%{build_ldflags}"`
		`- -Wl,-z,relro -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld`
		`+ $ rpm --eval "%{build_ldflags}"`
		`+ -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1`
		`....`

guidelines/modules/ROOT/pages/index.adoc

file modified

-4

		`@@ -1317,10 +1317,6 @@`
		`if there's a good reason to do so;`
		`the rationale for doing so must be documented in the specfile.`

		`- There are certain, security related flags that are commonly allowed.`
		`- These flags may degrade performance slightly`
		`- but the increased security can be worthwhile for some programs.`
		`-`
		`=== PIE`

		`PIE adds security to executables`

oturpe commented 2 years ago

Add named anchor to a section in RPMMacros.adoc.
The index page already attempts to link to such anchor,
but fails because it is not defined.
Update the example results for optflags and build_ldflags
to match Fedora 36 configuration,
up from Fedora 28.
Remove a paragraph about allowing adding some security related build
flags.
This is a reference to the PIE section immediately after,
but at some point, PIE became the default and that section does not
suggest adding any flags any more.

decathorpe commented 2 years ago

I wonder whether we should actually list the actually evaluated macros in the documentation? That tends to become outdated fast (as we see here). Maybe just saying "use rpm --eval %_build_cflags on the target to see the compiler flags that are in effect" would be more future-proof?

oturpe commented 2 years ago

I wonder whether we should actually list the actually evaluated macros in the documentation? That tends to become outdated fast (as we see here). Maybe just saying "use rpm --eval %_build_cflags on the target to see the compiler flags that are in effect" would be more future-proof?

I was wondering about that also when I saw the listing.
One downside I can think is that checking what the flags are requires a Fedora installation.
Probably that is not a real issue,
I support not many people package for Fedora using some other environment.
I will wait a bit to see if somebody has a different opinion,
if not, I will adjust this pull request accordingly.