From: Thilo Fromm <t.fromm@dresearch.de>
To: openembedded-devel@lists.openembedded.org
Subject: Re: [PATCH] libunwind: force gcc to be built first
Date: Fri, 01 Oct 2010 12:09:12 +0200 [thread overview]
Message-ID: <4CA5B348.1000404@dresearch.de> (raw)
In-Reply-To: <AANLkTimOEDXH3=OrROehD+sVtNdihoO8Q3P6Vy0oJscQ@mail.gmail.com>
Hello Frans, hello Khem,
>>>> 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)
They both provide unwind.h. For the library this is a "public" header
file, though, describing the interface to libunwind. It's exported by
libunwind. For some reason the libunwind version is used by gcc when gcc
is compiled.
>>> 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.
OK, I see. I ran a test build, and you're right, this is what happens.
Well, at least a clean build works with my small patch.
However, it looks like the maintainer of the gcc recipe needs to lake a
look at this. I CCed this mal directly to Khem to get some attention to
this issue.
>>> 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.
I tracked it down - libunwind publishes unwind.h, and gcc uses an
internal file of the same name while being built.
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
next prev parent reply other threads:[~2010-10-01 10:10 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 [this message]
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=4CA5B348.1000404@dresearch.de \
--to=t.fromm@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.