From: Tom Rini <tom_rini@mentor.com>
To: openembedded-devel@lists.openembedded.org
Subject: Re: [PATCH] libunwind: force gcc to be built first
Date: Mon, 14 Feb 2011 10:27:07 -0700 [thread overview]
Message-ID: <4D5965EB.1070607@mentor.com> (raw)
In-Reply-To: <4D58E883.8030606@dresearch.de>
On 02/14/2011 01:32 AM, Steffen Sledz wrote:
> Am 04.10.2010 18:00, schrieb Khem Raj:
>> On Mon, Oct 4, 2010 at 1:08 AM, Thilo Fromm<t.fromm@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!
Can you re-submit so it (a) hits patchwork again and (b) consolidate the
what's and whys and so forth in the commit message, if needed? Thanks!
--
Tom Rini
Mentor Graphics Corporation
next prev parent reply other threads:[~2011-02-14 17:28 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-29 16:17 [PATCH] libunwind: force gcc to be built first Thilo Fromm
2010-09-30 8:49 ` Steffen Sledz
2010-09-30 10:21 ` Frans Meulenbroeks
2010-09-30 10:47 ` Thilo Fromm
2010-09-30 11:30 ` Frans Meulenbroeks
2010-10-01 10:09 ` Thilo Fromm
2010-10-01 17:16 ` Khem Raj
2010-10-02 6:33 ` Frans Meulenbroeks
2010-10-04 8:08 ` Thilo Fromm
2010-10-04 16:00 ` Khem Raj
2011-02-14 8:32 ` Steffen Sledz
2011-02-14 17:27 ` Tom Rini [this message]
2011-02-14 17:58 ` Khem Raj
2011-02-14 19:10 ` Sledz, Steffen
2011-02-25 8:51 ` Steffen Sledz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D5965EB.1070607@mentor.com \
--to=tom_rini@mentor.com \
--cc=openembedded-devel@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox