All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
To: openembedded-devel@lists.openembedded.org
Subject: Re: [PATCH] libunwind: force gcc to be built first
Date: Thu, 30 Sep 2010 13:30:24 +0200	[thread overview]
Message-ID: <AANLkTimOEDXH3=OrROehD+sVtNdihoO8Q3P6Vy0oJscQ@mail.gmail.com> (raw)
In-Reply-To: <4CA46AD8.2070205@dresearch.de>

2010/9/30 Thilo Fromm <t.fromm@dresearch.de>:
> On 09/30/2010 12:21 PM, Frans Meulenbroeks wrote:
>
>>> It looks like libunwind provides header files that are named
>>> identically to gcc header files. gcc then confuses these headers when it
>>> is built, causing a break of the build.
>>>
>>> This patch makes libunwind depend on gcc which resolves the build issue.
>>> Both
>>> build nicely when gcc is built first.
>>
>> Hm. Ideally this should be patched in gcc.
>
> I don't think this is a gcc issue. It's a reasonable point of view, right,
> but pushing the header file issue back to libunwind is a valid POV, too. I
> think it's rather a problem between those two packages.

Well I don't know the exact cause:
if libunwind publishes a header X.h and gcc has an internal header
file X.h and picks the wrong one then clearly the way it searches the
include dirs is wrong.
if both publish X.h and they are incompatible then there is a
conflict, and some other package could pick up the wrong X.h too.

(and it could also be the case that libunwind does publish a file
which it should not publish as it is an internal file)
>
>> Now I feel that if someone
>>
>> does a bitbake libunwind; bitbake -cclean gcc; bitbake gcc things
>> still fail.
>
> Did you give this a try? I'll check it as soon as I can.

I haven't; I'm not behind my build system atm.

The issue that I see is that the last gcc build still may pick up the
libunwind header.
>
>> Btw what include files are we talking about?
>
> I took word from Steffen (Sledz) about the cause of the problem, so I didn't
> investigate any further. Introducing the dependency seemed to fix the
> problem, so why bother. However, I feel like this kind of problem is better
> fixed (the way you're proposing it) by the package maintainer, if there is
> one.

I'd rather know the root cause.
A fix without the root cause being known, often ends up to be
something that just masks the problem.
No idea if there is a libunwind maintainer.
gcc maintainer is Khem Raj.

BTW thanks for your efforts on this & have fun! Frans
>
> Regards,
> Thilo
>
> --
> Dipl.-Ing (FH) Thilo Fromm, MSc., Embedded Systems Developer
> DResearch Digital Media Systems GmbH
> Otto-Schmirgal-Str. 3, D-10319 Berlin, Germany
> Tel: +49 (30) 515 932 228   mailto:t.fromm@dresearch.de
> Fax: +49 (30) 515 932 77    http://www.dresearch.de
> Amtsgericht: Berlin Charlottenburg, HRB:54412
> Ust.-IDNr. DE169013825; WEEE Reg.-Nr. DE 85995642
> Geschäftsführer: Dr. M. Weber, W. Mögle
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>



  reply	other threads:[~2010-09-30 11:30 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 [this message]
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

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='AANLkTimOEDXH3=OrROehD+sVtNdihoO8Q3P6Vy0oJscQ@mail.gmail.com' \
    --to=fransmeulenbroeks@gmail.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 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.