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

[Thilo Fromm]

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 at 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