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.fr...@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
