[oe] [PATCH] libunwind: force gcc to be built first

[Khem Raj]

On Mon, Feb 14, 2011 at 12:32 AM, Steffen Sledz <sledz at dresearch.de> wrote:
> Am 04.10.2010 18:00, schrieb Khem Raj:
>> On Mon, Oct 4, 2010 at 1:08 AM, Thilo Fromm <t.fromm at dresearch.de> wrote:
>>> Hello Frans,
>>>
>>>>>> I tracked it down - libunwind publishes unwind.h, and gcc uses an
>>>>>> internal
>>>>>> file of the same name while being built.
>>>>>
>>>>> Yes gcc has its own version of libunwind which it used unless
>>>>> configured with --with-system-libunwind
>>>>> IIUC the problem happens with target gcc not with cross-gcc. target
>>>>> gcc is built using cross-gcc and
>>>>> <sysroot>/use/include could be preferred over the location of
>>>>> libunwind.h which is in gcc sources
>>>>> If thats the case then we need to fix gcc build to not look into
>>>>> standard sysroot/usr/include but prefer
>>>>> the local unwind.h when its using internal libunwind. The problem
>>>>> would not show up if the libunwind versions
>>>>> were matching but that may not be the case always and I dont know of
>>>>> hand how we can fix the gcc configury/build
>>>>> to ignore installed unwind.h
>>>>>
>>>>> You workaround would only work if build sequence was followed if some
>>>>> one just cleaned gcc and rebuild it
>>>>> the problem will resurface.
>>>>>
>>>> Thanks for the analysis Khem.
>>>> This is indeed more or less what I had expected.
>>>>
>>>> For me this patch gets a NAK as it does only masks the problvem in
>>>> some cases but not really solves it.
>>>
>>> You're right with this analysis; however, the patch enables Openembedded to
>>> be built *at all*. If you care less about whether you're able to actually
>>> build and if you have the time to wait until someone ventures deep into the
>>> gcc build and fixes the cause, then this is the way to go.
>>>
>>> For us, however, this patch is a valid workaround. It will make Openembedded
>>> work for us until the original issue is fixed.
>>
>> I think we should try to fix it in right way.
>
> Ping!

I think this patch does not fix the problem but hides it. It will not
be worth to get it upstream


>
> --
> DResearch Fahrzeugelektronik GmbH
> Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
> Tel: +49 30 515932-237 mailto:sledz at DResearch.de
> Fax: +49 30 515932-299
> Geschäftsführer: Dr. Michael Weber, Werner Mögle;
> Amtsgericht Berlin Charlottenburg; HRB 130120 B;
> Ust.-IDNr. DE273952058
>
>