[oe] [meta-networking][PATCH v2 2/2] meta-networking: override SECURITY_CFLAGS for c-ares

[André Draszik]

On Mo, 2016-07-18 at 02:52 -0700, Khem Raj wrote:
> > 
> > On Jul 18, 2016, at 2:46 AM, André Draszik <git at andred.net> wrote:
> > 
> > On Mo, 2016-07-18 at 01:37 -0700, Andre McCurdy wrote:
> > > 
> > > On Mon, Jul 18, 2016 at 1:16 AM, Khem Raj <raj.khem at gmail.com> wrote:
> > > > 
> > > > 
> > > > On Mon, Jul 18, 2016 at 1:03 AM <git at andred.net> wrote:
> > > > 
> > > > > 
> > > > > 
> > > > > From: André Draszik <adraszik at tycoint.com>
> > > > > 
> > > > > c-ares doesn't build if the distro has enabled usage of the
> > > > > security_flags.inc file as it is picky about what is placed
> > > > > into CPPFLAGS and CFLAGS. It complains and errors out if any
> > > > > preprocessor options appear in CFLAGS.
> > > 
> > > Curl (on which c-ares's configure files seem to be based) used to have
> > > the same problem but was fixed upstream by:
> > > 
> > > 
> > > https://github.com/curl/curl/commit/5d3cbde72ece7d83c280492957a26e26ab
> > > 4e5c
> > > ca
> > 
> > I must say I agree with c-ares' error here, and this really highlights a
> > bug
> > in how OE handles the security flags. By convention, preprocessor flags
> > belong into CPPFLAGS, not CFLAGS.
> > 
> > The real solution hence should be to have OE place -D flags (including
> > ${lcl_maybe_fortify} into CPPFLAGS, not CFLAGS in the first place.
> 
> right. Would you might sending a patch for OE-core
> 
> > 
> > 
> > But that'd be a change I am not in a position to test, as it would touch
> > everything. E.g. there might be build-environments that (silently)
> > ignore
> > user-supplied CPPFLAGS completely (cmake being one of those [1]).
> 
> Auto builders can help. Do whatever testing you can do. On minimum add the
> flags
> to CPPFLAGS

Looking around a little bit, I don't think this is feasible.

meta/conf/bitbake.conf unconditionally adds TARGET_CPPFLAGS to
TARGET_CFLAGS. So adding the flag to CPPFLAGS alone isn't going to do much,
we'd just have it in the compiler command line thrice.

Moving the flag from CFLAGS to CPPFLAGS by default is not going to be
feasible either.
I was under the impression that any recipe that inherits autotools*.bbclass
would continue to work fine, but various projects use hand-crafted
Makefile.in which again don't respect CPPFLAGS.

I could split out CPPFLAGS from SECURITY_CFLAGS in oe-core:

SECURITY_CFLAGS_NO_CPPFLAGS ?= "-fstack-protector-strong -pie -fpie ${SECURITY_STRINGFORMAT}"
SECURITY_CFLAGS ?= "${SECURITY_CFLAGS_NO_CPPFLAGS} ${lcl_maybe_fortify}"

Then I could in meta-openembedded:

lcl_maybe_fortify ?= ""
SECURITY_CFLAGS_pn-c-ares = "${SECURITY_CFLAGS_NO_CPPFLAGS}"
TARGET_CPPFLAGS_append_pn-c-ares = "${lcl_maybe_fortify}"

(but I'd also have to
TARGET_CFLAGS_remove = "${TARGET_CPPFLAGS}"
in c-ares.bb due to bitbake.conf)


This all looks like lots of churn and I don't think that's much better than
what I proposed originally. What do you think?


Cheers,
Andre'