[OE-core] [PATCH 1/3] bitbake.conf: Prune global OPTIMIZATION flags

[Gary Thomas]

On 03/29/2011 07:31 PM, Khem Raj wrote:
> On Tue, Mar 29, 2011 at 4:53 PM, Gary Thomas<gary at mlbassoc.com>  wrote:
>> On 03/29/2011 09:00 AM, Khem Raj wrote:
>>>
>>> On (29/03/11 14:34), Richard Purdie wrote:
>>>>
>>>> On Mon, 2011-03-21 at 11:11 -0700, Khem Raj wrote:
>>>>>
>>>>> -fexpensive-optimizations is enabled by default at -O2
>>>>>
>>>>> -fomit-frame-pointer is enabled at -O2 selectively by gcc depending upon
>>>>>    architecture if debug info is not hurt
>>>>>
>>>>> -frename-registers - This might have some performance advantage on top
>>>>>   of O2 on architectures which have more registers and registers are left
>>>>>   after scheduling but it affects debuggability quite a bit so as a i
>>>>>   tradeoff we do not use it.
>>>>>
>>>>> -feliminate-dwarf2-dups - We use this option to reduce the size of debug
>>>>>   information by removing duplicates this is only valid for dwarf2+ and
>>>>> we
>>>>>   use dwarf2 by default
>>>>
>>>> I've disabled this flag for now as it was causing too many failures
>>>> across the board (various apps, prelinker). We can add it back when this
>>>> has been tested more extensively and its been confirmed to work with the
>>>> prelinker.
>>>
>>> It would have been better to disable one by one we would be able to
>>> utilize current testing. Most probaly the prelink issue is due to
>>> -feliminate-dwarf2-dups did you try to remove that out ?
>>
>> This change, in particular adding -feliminate-dwarf2-dups, breaks my
>> build of chromium(*) (in strange ways, it ends up building .a libraries
>> which the linker can't parse).  Everything else I've tried to build
>> seems OK though.  For now, I've just dropped this option in my DISTRO.conf
>
> You dont have to after Richard already dropped it from bitbake.conf
> its better to stay close enough to defaults

Absolutely.  Thanks, Richard, for moving quickly on this.

>>
>> (*) It took quite some time to isolate this as the problem as it is a royal
>> pain to test BTW as it takes more than an hour to build this one package on
>> my
>> hefty build server!
>
> hmmm I wonder if its disabling PARALLE_MAKE ?

Nah, it's just *HUGE* - the tmp/work build tree is ~8GB

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------