[meta-networking][PATCH v2 1/2] c-ares: use our compilation flags

[meta-networking][PATCH v2 1/2] c-ares: use our compilation flags

[git]

From: André Draszik <adraszik@tycoint.com>

If not requested otherwise as ./configure option, c-ares will strip
any -g from CFLAGS / CPPFLAGS and add -g0 instead, disabling all
debug info.
Similarly, it will try to enable optimisation (but bail out since in
that case it honors an existing -O in CFLAGS / CPPFLAGS)

Since we want to control code generation, patch out the code
mangling -g (and -O for consistency). Alternatively, if we were to
pass --enable-debug to ./configure, c-ares would at the same time
assume that we don't want optimisation anymore.

Signed-off-by: André Draszik <adraszik@tycoint.com>
---
 ...configure.ac-don-t-override-passed-cflags.patch | 26 ++++++++++++++++++++++
 .../recipes-support/c-ares/c-ares_1.11.0.bb        |  4 +++-
 2 files changed, 29 insertions(+), 1 deletion(-)
 create mode 100644 meta-networking/recipes-support/c-ares/c-ares/0001-configure.ac-don-t-override-passed-cflags.patch

diff --git a/meta-networking/recipes-support/c-ares/c-ares/0001-configure.ac-don-t-override-passed-cflags.patch b/meta-networking/recipes-support/c-ares/c-ares/0001-configure.ac-don-t-override-passed-cflags.patch
new file mode 100644
index 0000000..10fad4e
--- /dev/null
+++ b/meta-networking/recipes-support/c-ares/c-ares/0001-configure.ac-don-t-override-passed-cflags.patch
@@ -0,0 +1,26 @@
+From 2a7236d2a7bb9c3d3c3f44ebf59404bf7134fcb3 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Andr=C3=A9=20Draszik?= <adraszik@tycoint.com>
+Date: Tue, 12 Apr 2016 11:37:28 +0100
+Subject: [PATCH] configure.ac: don't override passed cflags
+
+We are controlling debug and optimiser flags from OE
+---
+ configure.ac | 2 --
+ 1 file changed, 2 deletions(-)
+
+diff --git a/configure.ac b/configure.ac
+index 5c02450..3cf9fcd 100644
+--- a/configure.ac
++++ b/configure.ac
+@@ -147,8 +147,6 @@ dnl **********************************************************************
+ 
+ CARES_CHECK_COMPILER
+ CARES_SET_COMPILER_BASIC_OPTS
+-CARES_SET_COMPILER_DEBUG_OPTS
+-CARES_SET_COMPILER_OPTIMIZE_OPTS
+ CARES_SET_COMPILER_WARNING_OPTS
+ 
+ if test "$compiler_id" = "INTEL_UNIX_C"; then
+-- 
+2.8.0.rc3
+
diff --git a/meta-networking/recipes-support/c-ares/c-ares_1.11.0.bb b/meta-networking/recipes-support/c-ares/c-ares_1.11.0.bb
index 2f72ab4..c98be7d 100644
--- a/meta-networking/recipes-support/c-ares/c-ares_1.11.0.bb
+++ b/meta-networking/recipes-support/c-ares/c-ares_1.11.0.bb
@@ -6,7 +6,9 @@ SECTION = "libs"
 LICENSE = "MIT"
 LIC_FILES_CHKSUM = "file://ares_init.c;beginline=1;endline=3;md5=53f5ecf4c22c37cf1ddd1ef8f8eccce0"
 
-SRC_URI = "http://c-ares.haxx.se/download/${BP}.tar.gz"
+SRC_URI = "http://c-ares.haxx.se/download/${BP}.tar.gz \
+           file://0001-configure.ac-don-t-override-passed-cflags.patch \
+"
 SRC_URI[md5sum] = "d5c6d522cfc54bb6f215a0b7912d46be"
 SRC_URI[sha256sum] = "b3612e6617d9682928a1d50c1040de4db6519f977f0b25d40cf1b632900b3efd"
 
-- 
2.8.1

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

[git]

From: André Draszik <adraszik@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.

Fix this by providing an additional include file that is
require'd from conf/layer.conf which for c-ares moves the
defines added by security_flags.inc from CFLAGS to CPPFLAGS.

Signed-off-by: André Draszik <adraszik@tycoint.com>
---
 .../conf/distro/include/meta_networking_security_flags.inc          | 6 ++++++
 meta-networking/conf/layer.conf                                     | 3 +++
 2 files changed, 9 insertions(+)
 create mode 100644 meta-networking/conf/distro/include/meta_networking_security_flags.inc

diff --git a/meta-networking/conf/distro/include/meta_networking_security_flags.inc b/meta-networking/conf/distro/include/meta_networking_security_flags.inc
new file mode 100644
index 0000000..06802d6
--- /dev/null
+++ b/meta-networking/conf/distro/include/meta_networking_security_flags.inc
@@ -0,0 +1,6 @@
+# configure righteously complains:
+# | configure:3479: using CFLAGS:  -O2 -pipe -g -feliminate-unused-debug-types -fstack-protector-strong -pie -fpie -D_FORTIFY_SOURCE=2
+# | configure:3485: CFLAGS error: CFLAGS may only be used to specify C compiler flags, not macro definitions. Use CPPFLAGS for: -D_FORTIFY_SOURCE=2
+# | configure:3516: error: Can not continue. Fix errors mentioned immediately above this line.
+TARGET_CFLAGS_remove_pn-c-ares = "${lcl_maybe_fortify}"
+TARGET_CPPFLAGS_append_pn-c-ares = "${lcl_maybe_fortify}"
diff --git a/meta-networking/conf/layer.conf b/meta-networking/conf/layer.conf
index 5fd636a..c09ba4a 100644
--- a/meta-networking/conf/layer.conf
+++ b/meta-networking/conf/layer.conf
@@ -21,3 +21,6 @@ LICENSE_PATH += "${LAYERDIR}/licenses"
 
 # used by waf-samba.bbclass
 WAF_CROSS_ANSWERS_PATH = "${LAYERDIR}/files/waf-cross-answers"
+
+# Override security flags
+require conf/distro/include/meta_networking_security_flags.inc
-- 
2.8.1

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

[Khem Raj]

On Mon, Jul 18, 2016 at 1:03 AM <git@andred.net> wrote:

> From: André Draszik <adraszik@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.
>
> Fix this by providing an additional include file that is
> require'd from conf/layer.conf which for c-ares moves the
> defines added by security_flags.inc from CFLAGS to CPPFLAGS.
>
> Signed-off-by: André Draszik <adraszik@tycoint.com>
> ---
>  .../conf/distro/include/meta_networking_security_flags.inc          | 6
> ++++++
>  meta-networking/conf/layer.conf                                     | 3
> +++
>  2 files changed, 9 insertions(+)
>  create mode 100644
> meta-networking/conf/distro/include/meta_networking_security_flags.inc
>
> diff --git
> a/meta-networking/conf/distro/include/meta_networking_security_flags.inc
> b/meta-networking/conf/distro/include/meta_networking_security_flags.inc
> new file mode 100644
> index 0000000..06802d6
> --- /dev/null
> +++
> b/meta-networking/conf/distro/include/meta_networking_security_flags.inc
> @@ -0,0 +1,6 @@
> +# configure righteously complains:
> +# | configure:3479: using CFLAGS:  -O2 -pipe -g
> -feliminate-unused-debug-types -fstack-protector-strong -pie -fpie
> -D_FORTIFY_SOURCE=2
> +# | configure:3485: CFLAGS error: CFLAGS may only be used to specify C
> compiler flags, not macro definitions. Use CPPFLAGS for: -D_FORTIFY_SOURCE=2
> +# | configure:3516: error: Can not continue. Fix errors mentioned
> immediately above this line.
> +TARGET_CFLAGS_remove_pn-c-ares = "${lcl_maybe_fortify}"
> +TARGET_CPPFLAGS_append_pn-c-ares = "${lcl_maybe_fortify}"
>

will

lcl_maybe_fortify_pn-c-area = ""

work ?


> diff --git a/meta-networking/conf/layer.conf
> b/meta-networking/conf/layer.conf
> index 5fd636a..c09ba4a 100644
> --- a/meta-networking/conf/layer.conf
> +++ b/meta-networking/conf/layer.conf
> @@ -21,3 +21,6 @@ LICENSE_PATH += "${LAYERDIR}/licenses"
>
>  # used by waf-samba.bbclass
>  WAF_CROSS_ANSWERS_PATH = "${LAYERDIR}/files/waf-cross-answers"
> +
> +# Override security flags
> +require conf/distro/include/meta_networking_security_flags.inc
> --
> 2.8.1
>
> --
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>

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

[Andre McCurdy]

On Mon, Jul 18, 2016 at 1:16 AM, Khem Raj <raj.khem@gmail.com> wrote:
> On Mon, Jul 18, 2016 at 1:03 AM <git@andred.net> wrote:
>
>> From: André Draszik <adraszik@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/5d3cbde72ece7d83c280492957a26e26ab4e5cca

>> Fix this by providing an additional include file that is
>> require'd from conf/layer.conf which for c-ares moves the
>> defines added by security_flags.inc from CFLAGS to CPPFLAGS.
>>
>> Signed-off-by: André Draszik <adraszik@tycoint.com>
>> ---
>>  .../conf/distro/include/meta_networking_security_flags.inc          | 6
>> ++++++
>>  meta-networking/conf/layer.conf                                     | 3
>> +++
>>  2 files changed, 9 insertions(+)
>>  create mode 100644
>> meta-networking/conf/distro/include/meta_networking_security_flags.inc
>>
>> diff --git
>> a/meta-networking/conf/distro/include/meta_networking_security_flags.inc
>> b/meta-networking/conf/distro/include/meta_networking_security_flags.inc
>> new file mode 100644
>> index 0000000..06802d6
>> --- /dev/null
>> +++
>> b/meta-networking/conf/distro/include/meta_networking_security_flags.inc
>> @@ -0,0 +1,6 @@
>> +# configure righteously complains:
>> +# | configure:3479: using CFLAGS:  -O2 -pipe -g
>> -feliminate-unused-debug-types -fstack-protector-strong -pie -fpie
>> -D_FORTIFY_SOURCE=2
>> +# | configure:3485: CFLAGS error: CFLAGS may only be used to specify C
>> compiler flags, not macro definitions. Use CPPFLAGS for: -D_FORTIFY_SOURCE=2
>> +# | configure:3516: error: Can not continue. Fix errors mentioned
>> immediately above this line.
>> +TARGET_CFLAGS_remove_pn-c-ares = "${lcl_maybe_fortify}"
>> +TARGET_CPPFLAGS_append_pn-c-ares = "${lcl_maybe_fortify}"
>>
>
> will
>
> lcl_maybe_fortify_pn-c-area = ""
>
> work ?
>
>
>> diff --git a/meta-networking/conf/layer.conf
>> b/meta-networking/conf/layer.conf
>> index 5fd636a..c09ba4a 100644
>> --- a/meta-networking/conf/layer.conf
>> +++ b/meta-networking/conf/layer.conf
>> @@ -21,3 +21,6 @@ LICENSE_PATH += "${LAYERDIR}/licenses"
>>
>>  # used by waf-samba.bbclass
>>  WAF_CROSS_ANSWERS_PATH = "${LAYERDIR}/files/waf-cross-answers"
>> +
>> +# Override security flags
>> +require conf/distro/include/meta_networking_security_flags.inc
>> --
>> 2.8.1
>>
>> --
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>>
> --
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel

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

[André Draszik]

On Mo, 2016-07-18 at 08:16 +0000, Khem Raj wrote:
> On Mon, Jul 18, 2016 at 1:03 AM <git@andred.net> wrote:
> 
> > 
> > From: André Draszik <adraszik@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.
> > 
> > Fix this by providing an additional include file that is
> > require'd from conf/layer.conf which for c-ares moves the
> > defines added by security_flags.inc from CFLAGS to CPPFLAGS.
> > 
> > Signed-off-by: André Draszik <adraszik@tycoint.com>
> > ---
> >  .../conf/distro/include/meta_networking_security_flags.inc          | 6
> > ++++++
> >  meta-networking/conf/layer.conf                                     | 3
> > +++
> >  2 files changed, 9 insertions(+)
> >  create mode 100644
> > meta-networking/conf/distro/include/meta_networking_security_flags.inc
> > 
> > diff --git
> > a/meta-networking/conf/distro/include/meta_networking_security_flags.inc
> > b/meta-networking/conf/distro/include/meta_networking_security_flags.inc
> > new file mode 100644
> > index 0000000..06802d6
> > --- /dev/null
> > +++
> > b/meta-networking/conf/distro/include/meta_networking_security_flags.inc
> > @@ -0,0 +1,6 @@
> > +# configure righteously complains:
> > +# | configure:3479: using CFLAGS:  -O2 -pipe -g
> > -feliminate-unused-debug-types -fstack-protector-strong -pie -fpie
> > -D_FORTIFY_SOURCE=2
> > +# | configure:3485: CFLAGS error: CFLAGS may only be used to specify C
> > compiler flags, not macro definitions. Use CPPFLAGS for:
> > -D_FORTIFY_SOURCE=2
> > +# | configure:3516: error: Can not continue. Fix errors mentioned
> > immediately above this line.
> > +TARGET_CFLAGS_remove_pn-c-ares = "${lcl_maybe_fortify}"
> > +TARGET_CPPFLAGS_append_pn-c-ares = "${lcl_maybe_fortify}"
> > 
> 
> will
> 
> lcl_maybe_fortify_pn-c-area = ""
> 
> work ?

But that would remove -D_FORTIFY_SOURCE=2 completely...

I don't want to remove it, I just want to move it from CFLAGS to CPPFLAGS,
without adding further knowledge here about  what else is in
SECURITY_CFLAGS.

a.

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

[André Draszik]

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@gmail.com> wrote:
> > 
> > On Mon, Jul 18, 2016 at 1:03 AM <git@andred.net> wrote:
> > 
> > > 
> > > From: André Draszik <adraszik@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/5d3cbde72ece7d83c280492957a26e26ab4e5c
> 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.

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]).

a.

[1]
https://gitlab.kitware.com/cmake/cmake/issues/12928
https://cmake.org/Bug/view.php?id=12928

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

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 1866 bytes --]


> On Jul 18, 2016, at 2:46 AM, André Draszik <git@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@gmail.com> wrote:
>>> 
>>> On Mon, Jul 18, 2016 at 1:03 AM <git@andred.net> wrote:
>>> 
>>>> 
>>>> From: André Draszik <adraszik@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/5d3cbde72ece7d83c280492957a26e26ab4e5c
>> 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

> 
> a.
> 
> [1]
> https://gitlab.kitware.com/cmake/cmake/issues/12928
> https://cmake.org/Bug/view.php?id=12928
> --
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

Re: [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@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@gmail.com> wrote:
> > > > 
> > > > 
> > > > On Mon, Jul 18, 2016 at 1:03 AM <git@andred.net> wrote:
> > > > 
> > > > > 
> > > > > 
> > > > > From: André Draszik <adraszik@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'