TARGET_CFLAGS for non-target builds

TARGET_CFLAGS for non-target builds

[Andre McCurdy]

Although I don't see it on the mailing list, oe-core master now
contains the following patch:

  http://git.openembedded.org/openembedded-core/commit/?id=ff2c8af73046f55aa733ce8289b6236c88300290

Is this necessary? Aren't TARGET_CFLAGS by definition only used for the target?

Re: TARGET_CFLAGS for non-target builds

[Khem Raj]

On Mon, Feb 8, 2016 at 11:52 AM, Andre McCurdy <armccurdy@gmail.com> wrote:
> Although I don't see it on the mailing list, oe-core master now
> contains the following patch:
>
>   http://git.openembedded.org/openembedded-core/commit/?id=ff2c8af73046f55aa733ce8289b6236c88300290
>
> Is this necessary? Aren't TARGET_CFLAGS by definition only used for the target?

when doing native class TARGET_FLAGS are mutated to represent build
flags but it still is TARGET_FLAGS
and when you append to it then the flags go into your
native/cross/nativesdk builds as well. Not something you
are looking for.

> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: TARGET_CFLAGS for non-target builds

[Andre McCurdy]

On Mon, Feb 8, 2016 at 11:57 AM, Khem Raj <raj.khem@gmail.com> wrote:
> On Mon, Feb 8, 2016 at 11:52 AM, Andre McCurdy <armccurdy@gmail.com> wrote:
>> Although I don't see it on the mailing list, oe-core master now
>> contains the following patch:
>>
>>   http://git.openembedded.org/openembedded-core/commit/?id=ff2c8af73046f55aa733ce8289b6236c88300290
>>
>> Is this necessary? Aren't TARGET_CFLAGS by definition only used for the target?
>
> when doing native class TARGET_FLAGS are mutated to represent build
> flags but it still is TARGET_FLAGS
> and when you append to it then the flags go into your
> native/cross/nativesdk builds as well. Not something you
> are looking for.

Can you give an example? Looking at native.bbclass it seems to replace
TARGET_CFLAGS with BUILD_CFLAGS, not manipulate it.

(I've had -fstack-protector-strong in SECURITY_CFLAGS in my own distro
for a long time and all the build failures it caused for native
packages have turned out to be bugs in the packages or the recipes).

>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: TARGET_CFLAGS for non-target builds

[Burton, Ross]

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

On 8 February 2016 at 20:03, Andre McCurdy <armccurdy@gmail.com> wrote:

> Can you give an example? Looking at native.bbclass it seems to replace
> TARGET_CFLAGS with BUILD_CFLAGS, not manipulate it.
>

Sure, so in doing a native build TARGET_CFLAGS is used.  But as
security_flags.inc was using TARGET_CFLAGS_append, the end result was
BUILD_CFLAGS appended with the security flags.

Ross

[-- Attachment #2: Type: text/html, Size: 804 bytes --]

Re: TARGET_CFLAGS for non-target builds

[Andre McCurdy]

On Mon, Feb 8, 2016 at 3:00 PM, Burton, Ross <ross.burton@intel.com> wrote:
>
> On 8 February 2016 at 20:03, Andre McCurdy <armccurdy@gmail.com> wrote:
>>
>> Can you give an example? Looking at native.bbclass it seems to replace
>> TARGET_CFLAGS with BUILD_CFLAGS, not manipulate it.
>
> Sure, so in doing a native build TARGET_CFLAGS is used.  But as
> security_flags.inc was using TARGET_CFLAGS_append, the end result was
> BUILD_CFLAGS appended with the security flags.

Yes, for native, TARGET_CFLAGS will end up being "${BUILD_CFLAGS}
${SECURITY_CFLAGS}".

However it shouldn't matter - native.bbclass sets CFLAGS to
BUILD_CFLAGS, not TARGET_CFLAGS.

Do you have an example where host gcc can legitimately be invoked with
TARGET_CFLAGS?

> Ross

Re: TARGET_CFLAGS for non-target builds

[Mark Hatle]

On 2/8/16 5:43 PM, Andre McCurdy wrote:
> On Mon, Feb 8, 2016 at 3:00 PM, Burton, Ross <ross.burton@intel.com> wrote:
>>
>> On 8 February 2016 at 20:03, Andre McCurdy <armccurdy@gmail.com> wrote:
>>>
>>> Can you give an example? Looking at native.bbclass it seems to replace
>>> TARGET_CFLAGS with BUILD_CFLAGS, not manipulate it.
>>
>> Sure, so in doing a native build TARGET_CFLAGS is used.  But as
>> security_flags.inc was using TARGET_CFLAGS_append, the end result was
>> BUILD_CFLAGS appended with the security flags.
> 
> Yes, for native, TARGET_CFLAGS will end up being "${BUILD_CFLAGS}
> ${SECURITY_CFLAGS}".
> 
> However it shouldn't matter - native.bbclass sets CFLAGS to
> BUILD_CFLAGS, not TARGET_CFLAGS.
> 
> Do you have an example where host gcc can legitimately be invoked with
> TARGET_CFLAGS?

You have to remember the order of the operators.  _append says to make the
append, AFTER everything else has been evaluated (and before _remove).  This
includes override behaviors.

So if you do:

TARGET_CFLAGS = "-deadbeef"
BUILD_CFLAGS = "-badc0ffee"
TARGET_CFLAGS_append = " -foobar"
TARGET_CFLAGS = "${BUILD_CFLAGS}"

The final value of TARGET_CFLAGS is "-badc0ffee -foobar"

Thus by changing the append to:

TARGET_CFLAGS_append_class-target = " -foobar"
TARGET_CFLAGS_class-native = "${BUILD_CFLAGS}"

In the case where the 'class-target' is the override you will get:

TARGET_CFLAGS = "-deadbeef -foobar"

In the case where the 'class-native' is the override you will get:

TARGET_CFLAGS = "-badc0ffee"

--Mark

Re: TARGET_CFLAGS for non-target builds

[Andre McCurdy]

On Mon, Feb 8, 2016 at 4:01 PM, Mark Hatle <mark.hatle@windriver.com> wrote:
> On 2/8/16 5:43 PM, Andre McCurdy wrote:
>> On Mon, Feb 8, 2016 at 3:00 PM, Burton, Ross <ross.burton@intel.com> wrote:
>>>
>>> On 8 February 2016 at 20:03, Andre McCurdy <armccurdy@gmail.com> wrote:
>>>>
>>>> Can you give an example? Looking at native.bbclass it seems to replace
>>>> TARGET_CFLAGS with BUILD_CFLAGS, not manipulate it.
>>>
>>> Sure, so in doing a native build TARGET_CFLAGS is used.  But as
>>> security_flags.inc was using TARGET_CFLAGS_append, the end result was
>>> BUILD_CFLAGS appended with the security flags.
>>
>> Yes, for native, TARGET_CFLAGS will end up being "${BUILD_CFLAGS}
>> ${SECURITY_CFLAGS}".
>>
>> However it shouldn't matter - native.bbclass sets CFLAGS to
>> BUILD_CFLAGS, not TARGET_CFLAGS.
>>
>> Do you have an example where host gcc can legitimately be invoked with
>> TARGET_CFLAGS?
>
> You have to remember the order of the operators.  _append says to make the
> append, AFTER everything else has been evaluated (and before _remove).  This
> includes override behaviors.
>
> So if you do:
>
> TARGET_CFLAGS = "-deadbeef"
> BUILD_CFLAGS = "-badc0ffee"
> TARGET_CFLAGS_append = " -foobar"
> TARGET_CFLAGS = "${BUILD_CFLAGS}"
>
> The final value of TARGET_CFLAGS is "-badc0ffee -foobar"
>
> Thus by changing the append to:
>
> TARGET_CFLAGS_append_class-target = " -foobar"
> TARGET_CFLAGS_class-native = "${BUILD_CFLAGS}"
>
> In the case where the 'class-target' is the override you will get:
>
> TARGET_CFLAGS = "-deadbeef -foobar"
>
> In the case where the 'class-native' is the override you will get:
>
> TARGET_CFLAGS = "-badc0ffee"

I'm not disputing that TARGET_CFLAGS can contain something bogus for a
class-native build.

I'm asking why does it matter?

Setting TARGET_CFLAGS at all in native.bbclass is fairly recent and
seems to be a workaround to avoid churning sstate:

  http://git.openembedded.org/openembedded-core/commit/?id=05a70ac30b37cab0952f1b9df501993a9dec70da

Is that perhaps still the real reason to avoid modifying TARGET_CFLAGS
for a native build?


> --Mark

Re: TARGET_CFLAGS for non-target builds

[Christopher Larson]

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

Target_cflags is an exported variable. It affects the checksums of every
task. Not ideal, but that's how it is today.
On Mon, Feb 8, 2016 at 5:10 PM Andre McCurdy <armccurdy@gmail.com> wrote:

> On Mon, Feb 8, 2016 at 4:01 PM, Mark Hatle <mark.hatle@windriver.com>
> wrote:
> > On 2/8/16 5:43 PM, Andre McCurdy wrote:
> >> On Mon, Feb 8, 2016 at 3:00 PM, Burton, Ross <ross.burton@intel.com>
> wrote:
> >>>
> >>> On 8 February 2016 at 20:03, Andre McCurdy <armccurdy@gmail.com>
> wrote:
> >>>>
> >>>> Can you give an example? Looking at native.bbclass it seems to replace
> >>>> TARGET_CFLAGS with BUILD_CFLAGS, not manipulate it.
> >>>
> >>> Sure, so in doing a native build TARGET_CFLAGS is used.  But as
> >>> security_flags.inc was using TARGET_CFLAGS_append, the end result was
> >>> BUILD_CFLAGS appended with the security flags.
> >>
> >> Yes, for native, TARGET_CFLAGS will end up being "${BUILD_CFLAGS}
> >> ${SECURITY_CFLAGS}".
> >>
> >> However it shouldn't matter - native.bbclass sets CFLAGS to
> >> BUILD_CFLAGS, not TARGET_CFLAGS.
> >>
> >> Do you have an example where host gcc can legitimately be invoked with
> >> TARGET_CFLAGS?
> >
> > You have to remember the order of the operators.  _append says to make
> the
> > append, AFTER everything else has been evaluated (and before _remove).
> This
> > includes override behaviors.
> >
> > So if you do:
> >
> > TARGET_CFLAGS = "-deadbeef"
> > BUILD_CFLAGS = "-badc0ffee"
> > TARGET_CFLAGS_append = " -foobar"
> > TARGET_CFLAGS = "${BUILD_CFLAGS}"
> >
> > The final value of TARGET_CFLAGS is "-badc0ffee -foobar"
> >
> > Thus by changing the append to:
> >
> > TARGET_CFLAGS_append_class-target = " -foobar"
> > TARGET_CFLAGS_class-native = "${BUILD_CFLAGS}"
> >
> > In the case where the 'class-target' is the override you will get:
> >
> > TARGET_CFLAGS = "-deadbeef -foobar"
> >
> > In the case where the 'class-native' is the override you will get:
> >
> > TARGET_CFLAGS = "-badc0ffee"
>
> I'm not disputing that TARGET_CFLAGS can contain something bogus for a
> class-native build.
>
> I'm asking why does it matter?
>
> Setting TARGET_CFLAGS at all in native.bbclass is fairly recent and
> seems to be a workaround to avoid churning sstate:
>
>
> http://git.openembedded.org/openembedded-core/commit/?id=05a70ac30b37cab0952f1b9df501993a9dec70da
>
> Is that perhaps still the real reason to avoid modifying TARGET_CFLAGS
> for a native build?
>
>
> > --Mark
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

[-- Attachment #2: Type: text/html, Size: 3950 bytes --]

Re: TARGET_CFLAGS for non-target builds

[Andre McCurdy]

On Mon, Feb 8, 2016 at 4:13 PM, Christopher Larson <clarson@kergoth.com> wrote:
> Target_cflags is an exported variable. It affects the checksums of every
> task. Not ideal, but that's how it is today.

So why wouldn't we just set TARGET_CFLAGS etc to "" in native.bbclass?


> On Mon, Feb 8, 2016 at 5:10 PM Andre McCurdy <armccurdy@gmail.com> wrote:
>>
>> On Mon, Feb 8, 2016 at 4:01 PM, Mark Hatle <mark.hatle@windriver.com>
>> wrote:
>> > On 2/8/16 5:43 PM, Andre McCurdy wrote:
>> >> On Mon, Feb 8, 2016 at 3:00 PM, Burton, Ross <ross.burton@intel.com>
>> >> wrote:
>> >>>
>> >>> On 8 February 2016 at 20:03, Andre McCurdy <armccurdy@gmail.com>
>> >>> wrote:
>> >>>>
>> >>>> Can you give an example? Looking at native.bbclass it seems to
>> >>>> replace
>> >>>> TARGET_CFLAGS with BUILD_CFLAGS, not manipulate it.
>> >>>
>> >>> Sure, so in doing a native build TARGET_CFLAGS is used.  But as
>> >>> security_flags.inc was using TARGET_CFLAGS_append, the end result was
>> >>> BUILD_CFLAGS appended with the security flags.
>> >>
>> >> Yes, for native, TARGET_CFLAGS will end up being "${BUILD_CFLAGS}
>> >> ${SECURITY_CFLAGS}".
>> >>
>> >> However it shouldn't matter - native.bbclass sets CFLAGS to
>> >> BUILD_CFLAGS, not TARGET_CFLAGS.
>> >>
>> >> Do you have an example where host gcc can legitimately be invoked with
>> >> TARGET_CFLAGS?
>> >
>> > You have to remember the order of the operators.  _append says to make
>> > the
>> > append, AFTER everything else has been evaluated (and before _remove).
>> > This
>> > includes override behaviors.
>> >
>> > So if you do:
>> >
>> > TARGET_CFLAGS = "-deadbeef"
>> > BUILD_CFLAGS = "-badc0ffee"
>> > TARGET_CFLAGS_append = " -foobar"
>> > TARGET_CFLAGS = "${BUILD_CFLAGS}"
>> >
>> > The final value of TARGET_CFLAGS is "-badc0ffee -foobar"
>> >
>> > Thus by changing the append to:
>> >
>> > TARGET_CFLAGS_append_class-target = " -foobar"
>> > TARGET_CFLAGS_class-native = "${BUILD_CFLAGS}"
>> >
>> > In the case where the 'class-target' is the override you will get:
>> >
>> > TARGET_CFLAGS = "-deadbeef -foobar"
>> >
>> > In the case where the 'class-native' is the override you will get:
>> >
>> > TARGET_CFLAGS = "-badc0ffee"
>>
>> I'm not disputing that TARGET_CFLAGS can contain something bogus for a
>> class-native build.
>>
>> I'm asking why does it matter?
>>
>> Setting TARGET_CFLAGS at all in native.bbclass is fairly recent and
>> seems to be a workaround to avoid churning sstate:
>>
>>
>> http://git.openembedded.org/openembedded-core/commit/?id=05a70ac30b37cab0952f1b9df501993a9dec70da
>>
>> Is that perhaps still the real reason to avoid modifying TARGET_CFLAGS
>> for a native build?
>>
>>
>> > --Mark
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: TARGET_CFLAGS for non-target builds

[Andre McCurdy]

On Mon, Feb 8, 2016 at 4:29 PM, Andre McCurdy <armccurdy@gmail.com> wrote:
> On Mon, Feb 8, 2016 at 4:13 PM, Christopher Larson <clarson@kergoth.com> wrote:
>> Target_cflags is an exported variable. It affects the checksums of every
>> task. Not ideal, but that's how it is today.
>
> So why wouldn't we just set TARGET_CFLAGS etc to "" in native.bbclass?

... with an appropriate over-ride for SECURITY_CFLAGS too.

>
>
>> On Mon, Feb 8, 2016 at 5:10 PM Andre McCurdy <armccurdy@gmail.com> wrote:
>>>
>>> On Mon, Feb 8, 2016 at 4:01 PM, Mark Hatle <mark.hatle@windriver.com>
>>> wrote:
>>> > On 2/8/16 5:43 PM, Andre McCurdy wrote:
>>> >> On Mon, Feb 8, 2016 at 3:00 PM, Burton, Ross <ross.burton@intel.com>
>>> >> wrote:
>>> >>>
>>> >>> On 8 February 2016 at 20:03, Andre McCurdy <armccurdy@gmail.com>
>>> >>> wrote:
>>> >>>>
>>> >>>> Can you give an example? Looking at native.bbclass it seems to
>>> >>>> replace
>>> >>>> TARGET_CFLAGS with BUILD_CFLAGS, not manipulate it.
>>> >>>
>>> >>> Sure, so in doing a native build TARGET_CFLAGS is used.  But as
>>> >>> security_flags.inc was using TARGET_CFLAGS_append, the end result was
>>> >>> BUILD_CFLAGS appended with the security flags.
>>> >>
>>> >> Yes, for native, TARGET_CFLAGS will end up being "${BUILD_CFLAGS}
>>> >> ${SECURITY_CFLAGS}".
>>> >>
>>> >> However it shouldn't matter - native.bbclass sets CFLAGS to
>>> >> BUILD_CFLAGS, not TARGET_CFLAGS.
>>> >>
>>> >> Do you have an example where host gcc can legitimately be invoked with
>>> >> TARGET_CFLAGS?
>>> >
>>> > You have to remember the order of the operators.  _append says to make
>>> > the
>>> > append, AFTER everything else has been evaluated (and before _remove).
>>> > This
>>> > includes override behaviors.
>>> >
>>> > So if you do:
>>> >
>>> > TARGET_CFLAGS = "-deadbeef"
>>> > BUILD_CFLAGS = "-badc0ffee"
>>> > TARGET_CFLAGS_append = " -foobar"
>>> > TARGET_CFLAGS = "${BUILD_CFLAGS}"
>>> >
>>> > The final value of TARGET_CFLAGS is "-badc0ffee -foobar"
>>> >
>>> > Thus by changing the append to:
>>> >
>>> > TARGET_CFLAGS_append_class-target = " -foobar"
>>> > TARGET_CFLAGS_class-native = "${BUILD_CFLAGS}"
>>> >
>>> > In the case where the 'class-target' is the override you will get:
>>> >
>>> > TARGET_CFLAGS = "-deadbeef -foobar"
>>> >
>>> > In the case where the 'class-native' is the override you will get:
>>> >
>>> > TARGET_CFLAGS = "-badc0ffee"
>>>
>>> I'm not disputing that TARGET_CFLAGS can contain something bogus for a
>>> class-native build.
>>>
>>> I'm asking why does it matter?
>>>
>>> Setting TARGET_CFLAGS at all in native.bbclass is fairly recent and
>>> seems to be a workaround to avoid churning sstate:
>>>
>>>
>>> http://git.openembedded.org/openembedded-core/commit/?id=05a70ac30b37cab0952f1b9df501993a9dec70da
>>>
>>> Is that perhaps still the real reason to avoid modifying TARGET_CFLAGS
>>> for a native build?
>>>
>>>
>>> > --Mark
>>> --
>>> _______________________________________________
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: TARGET_CFLAGS for non-target builds

[Khem Raj]

On Mon, Feb 8, 2016 at 4:10 PM, Andre McCurdy <armccurdy@gmail.com> wrote:
> On Mon, Feb 8, 2016 at 4:01 PM, Mark Hatle <mark.hatle@windriver.com> wrote:
>> On 2/8/16 5:43 PM, Andre McCurdy wrote:
>>> On Mon, Feb 8, 2016 at 3:00 PM, Burton, Ross <ross.burton@intel.com> wrote:
>>>>
>>>> On 8 February 2016 at 20:03, Andre McCurdy <armccurdy@gmail.com> wrote:
>>>>>
>>>>> Can you give an example? Looking at native.bbclass it seems to replace
>>>>> TARGET_CFLAGS with BUILD_CFLAGS, not manipulate it.
>>>>
>>>> Sure, so in doing a native build TARGET_CFLAGS is used.  But as
>>>> security_flags.inc was using TARGET_CFLAGS_append, the end result was
>>>> BUILD_CFLAGS appended with the security flags.
>>>
>>> Yes, for native, TARGET_CFLAGS will end up being "${BUILD_CFLAGS}
>>> ${SECURITY_CFLAGS}".
>>>
>>> However it shouldn't matter - native.bbclass sets CFLAGS to
>>> BUILD_CFLAGS, not TARGET_CFLAGS.
>>>
>>> Do you have an example where host gcc can legitimately be invoked with
>>> TARGET_CFLAGS?
>>
>> You have to remember the order of the operators.  _append says to make the
>> append, AFTER everything else has been evaluated (and before _remove).  This
>> includes override behaviors.
>>
>> So if you do:
>>
>> TARGET_CFLAGS = "-deadbeef"
>> BUILD_CFLAGS = "-badc0ffee"
>> TARGET_CFLAGS_append = " -foobar"
>> TARGET_CFLAGS = "${BUILD_CFLAGS}"
>>
>> The final value of TARGET_CFLAGS is "-badc0ffee -foobar"
>>
>> Thus by changing the append to:
>>
>> TARGET_CFLAGS_append_class-target = " -foobar"
>> TARGET_CFLAGS_class-native = "${BUILD_CFLAGS}"
>>
>> In the case where the 'class-target' is the override you will get:
>>
>> TARGET_CFLAGS = "-deadbeef -foobar"
>>
>> In the case where the 'class-native' is the override you will get:
>>
>> TARGET_CFLAGS = "-badc0ffee"
>
> I'm not disputing that TARGET_CFLAGS can contain something bogus for a
> class-native build.
>
> I'm asking why does it matter?

there were recipes like efi-native and grub-native among others which
showed up failures with sec flags enabled
on older hosts where gcc did not support -fstack-protector-strong, so
it was silently accepting sec flags for native
builds since fstack-protector-all is an old enough gcc option that you
really did not see it in build hosts gcc complaining.

in anycase this is an improvement over what we were doing thus far and
clarifies the intent of recipe classes w.r.t sec flags

>
> Setting TARGET_CFLAGS at all in native.bbclass is fairly recent and
> seems to be a workaround to avoid churning sstate:
>
>   http://git.openembedded.org/openembedded-core/commit/?id=05a70ac30b37cab0952f1b9df501993a9dec70da
>
> Is that perhaps still the real reason to avoid modifying TARGET_CFLAGS
> for a native build?

well

>
>
>> --Mark
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core