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>

package/Makefile.in

@@ -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)