[OE-core] TARGET_CFLAGS for non-target builds

[Khem Raj]

On Mon, Feb 8, 2016 at 4:10 PM, Andre McCurdy <armccurdy at gmail.com> wrote:
> On Mon, Feb 8, 2016 at 4:01 PM, Mark Hatle <mark.hatle at 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 at intel.com> wrote:
>>>>
>>>> On 8 February 2016 at 20:03, Andre McCurdy <armccurdy at 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 at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core