All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steffen Sledz <sledz@dresearch.de>
To: openembedded-devel@lists.openembedded.org
Subject: Re: [PATCH] libunwind: force gcc to be built first
Date: Fri, 25 Feb 2011 09:51:09 +0100	[thread overview]
Message-ID: <4D676D7D.3050408@dresearch.de> (raw)
In-Reply-To: <DB561678F08F554EB0D9F21B70E268A505AF9A@exchange.intern.dresearch.de>

Am 14.02.2011 20:10, schrieb Sledz, Steffen:
> Am 14.02.2011 18:58, schrieb Khem Raj:
>> On Mon, Feb 14, 2011 at 12:32 AM, Steffen Sledz <sledz@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@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
> 
> That's right.
> 
> I read your comment from october 1st that you try to fix this "in the right way" by fixing "the gcc build to not look into standard sysroot/usr/include but prefer the local unwind.h when its using internal libunwind".

Ping!

-- 
DResearch Fahrzeugelektronik GmbH
Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
Tel: +49 30 515932-237 mailto:sledz@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




      reply	other threads:[~2011-02-25  8:52 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
2011-02-14 17:58                   ` Khem Raj
2011-02-14 19:10                     ` Sledz, Steffen
2011-02-25  8:51                       ` Steffen Sledz [this message]

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=4D676D7D.3050408@dresearch.de \
    --to=sledz@dresearch.de \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.