BR2_FORTIFY*: toolchain wrapper limitation note

A note is added to tie off the discussion on why moving _FORTIFY_SOURCE
related flags into the toolchain wrapper doesn't currently work.

 - Currently -D_FORTIFY_SOURCE and optimizations are passed through
   CFLAGS

 - Packages like linux-tools ignore CFLAGS entirely and some
   autotools toolchain testing cases dependent on not using
   CFLAGS.

 - If FORTIFY_SOURCE is passed through the wrapper, then linux-tools
   will no longer be able to ignore it, because it's enforced at a
   lower-level and since the optimization -Os/g/1/2/3 are via CFLAGS,
   there is no optimization flag set.  Therefore linux-tools will do
   all its configuration tests with FORTIFY_SOURCE forcefully enabled
   at the wrapper level, but no optimization enabled, and consequently
   tests will fail.

Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This commit is contained in:
Matt Weber 2018-09-17 16:21:51 -05:00 committed by Peter Korsgaard
parent f10822d151
commit 394bdd11fc

View File

@ -143,6 +143,15 @@ endif
TARGET_LDFLAGS = $(call qstrip,$(BR2_TARGET_LDFLAGS))
# By design, _FORTIFY_SOURCE requires gcc optimization to be enabled.
# Therefore, we need to pass _FORTIFY_SOURCE and the optimization level
# through the same mechanism, i.e currently through CFLAGS. Passing
# _FORTIFY_SOURCE through the wrapper and the optimization level
# through CFLAGS would not work, because CFLAGS are sometimes
# ignored/overridden by packages, but the flags passed by the wrapper
# are enforced: this would cause _FORTIFY_SOURCE to be used without any
# optimization level, leading to a build / configure failure. So we keep
# passing _FORTIFY_SOURCE and the optimization level both through CFLAGS.
ifeq ($(BR2_FORTIFY_SOURCE_1),y)
TARGET_HARDENED += -D_FORTIFY_SOURCE=1
else ifeq ($(BR2_FORTIFY_SOURCE_2),y)