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

[Khem Raj]

On Fri, Oct 1, 2010 at 3:09 AM, Thilo Fromm <t.fromm at dresearch.de> wrote:
> 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.

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.

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