* [PATCH] libunwind: force gcc to be built first @ 2010-09-29 16:17 Thilo Fromm 2010-09-30 8:49 ` Steffen Sledz 2010-09-30 10:21 ` Frans Meulenbroeks 0 siblings, 2 replies; 15+ messages in thread From: Thilo Fromm @ 2010-09-29 16:17 UTC (permalink / raw) To: openembedded-devel libunwind causes cross gcc build to fail if libunwind is built first: ... | arm-angstrom-linux-gnueabi-gcc -march=armv5te -mtune=arm926ej-s -mthumb-interwork -mno-thumb -march=armv5te -mtune=arm926ej-s -mthumb-interwork -mno-thumb -isystem/SCRATCH/maniac/oe-merge-test/OE/tmp.6/sysroots/armv5te-angstrom-linux-gnueabi/usr/include -g -Os -O2 -g -Os -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../.././gcc -I/SCRATCH/maniac/oe-merge-test/OE/tmp.6/work/armv5te-angstrom-linux-gnueabi/gcc-4.3.3-r17.1/gcc-4.3.3/libgcc -I/SCRATCH/maniac/oe-merge-test/OE/tmp.6/work/armv5te-angstrom-linux-gnueabi/gcc-4.3.3-r17.1/gcc-4.3.3/libgcc/. -I/SCRATCH/maniac/oe-merge-test/OE/tmp.6/work/armv5te-angstrom-linux-gnueabi/gcc-4.3.3-r17.1/gcc-4.3.3/libgcc/../gcc -I/SCRATCH/maniac/oe-merge-test/OE/tmp.6/work/armv5te-angstrom-linux-gnueabi/gcc-4.3.3-r17.1/gcc-4.3.3/libgcc/../include -DHAVE_CC_TLS -o _ucmpdi2_s.o -MT _ucmpdi2_s.o \ -MD -MP -MF _ucmpdi2_s.dep -DSHARED -DL_ucmpdi2 -c /SCRATCH/maniac/oe-merge-test/OE/tmp.6/work/armv5te-angstrom-linux-gnueabi/gcc-4.3.3-r17.1/gcc-4.3.3/libgcc/../gcc/libgcc2.c | /SCRATCH/maniac/oe-merge-test/OE/tmp.6/work/armv5te-angstrom-linux-gnueabi/gcc-4.3.3-r17.1/gcc-4.3.3/libgcc/../gcc/config/arm/unwind-arm.c:40: error: expected ')' before '*' token | /SCRATCH/maniac/oe-merge-test/OE/tmp.6/work/armv5te-angstrom-linux-gnueabi/gcc-4.3.3-r17.1/gcc-4.3.3/libgcc/../gcc/config/arm/unwind-arm.c:41: error: expected ')' before '*' token | /SCRATCH/maniac/oe-merge-test/OE/tmp.6/work/armv5te-angstrom-linux-gnueabi/gcc-4.3.3-r17.1/gcc-4.3.3/libgcc/../gcc/config/arm/unwind-arm.c:42: error: expected ')' before '*' token | /SCRATCH/maniac/oe-merge-test/OE/tmp.6/work/armv5te-angstrom-linux-gnueabi/gcc-4.3.3-r17.1/gcc-4.3.3/libgcc/../gcc/config/arm/unwind-arm.c:47: warning: data definition has no type or storage class ... | /SCRATCH/maniac/oe-merge-test/OE/tmp.6/work/armv5te-angstrom-linux-gnueabi/gcc-4.3.3-r17.1/gcc-4.3.3/libgcc/../gcc/config/arm/pr-support.c:396: error: expected '=', ',', ';', 'asm' or '__attribute__' before '_Unwind_GetDataRelBase' | /SCRATCH/maniac/oe-merge-test/OE/tmp.6/work/armv5te-angstrom-linux-gnueabi/gcc-4.3.3-r17.1/gcc-4.3.3/libgcc/../gcc/config/arm/pr-support.c:402: error: expected '=', ',', ';', 'asm' or '__attribute__' before '_Unwind_GetTextRelBase' | make[2]: *** [unwind-arm.o] Error 1 | make[2]: *** Waiting for unfinished jobs.... | make[2]: *** [pr-support.o] Error 1 ... | /SCRATCH/maniac/oe-merge-test/OE/tmp.6/work/armv5te-angstrom-linux-gnueabi/gcc-4.3.3-r17.1/gcc-4.3.3/libgcc/../gcc/unwind-c.c:212: error: 'lsda_header_info' has no member named 'LPStart' | /SCRATCH/maniac/oe-merge-test/OE/tmp.6/work/armv5te-angstrom-linux-gnueabi/gcc-4.3.3-r17.1/gcc-4.3.3/libgcc/../gcc/unwind-c.c:214: error: 'lsda_header_info' has no member named 'action_table' | /SCRATCH/maniac/oe-merge-test/OE/tmp.6/work/armv5te-angstrom-linux-gnueabi/gcc-4.3.3-r17.1/gcc-4.3.3/libgcc/../gcc/unwind-c.c:234: error: expected ')' before 'ue_header' | /SCRATCH/maniac/oe-merge-test/OE/tmp.6/work/armv5te-angstrom-linux-gnueabi/gcc-4.3.3-r17.1/gcc-4.3.3/libgcc/../gcc/unwind-c.c:123: warning: unused parameter 'ue_header' | make[2]: *** [unwind-c.o] Error 1 | make[2]: Leaving directory `/SCRATCH/maniac/oe-merge-test/OE/tmp.6/work/armv5te-angstrom-linux-gnueabi/gcc-4.3.3-r17.1/gcc-4.3.3/build.arm-angstrom-linux-gnueabi.arm-angstrom-linux-gnueabi/arm-angstrom-linux-gnueabi/libgcc' | make[1]: *** [all-target-libgcc] Error 2 | make[1]: Leaving directory `/SCRATCH/maniac/oe-merge-test/OE/tmp.6/work/armv5te-angstrom-linux-gnueabi/gcc-4.3.3-r17.1/gcc-4.3.3/build.arm-angstrom-linux-gnueabi.arm-angstrom-linux-gnueabi' | make: *** [all] Error 2 | FATAL: oe_runmake failed | ERROR: Function do_compile failed NOTE: package gcc-4.3.3-r17.1: task do_compile: Failed 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. Signed-off-by: Thilo Fromm <t.fromm@dresearch.de> --- recipes/libunwind/libunwind.inc | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/recipes/libunwind/libunwind.inc b/recipes/libunwind/libunwind.inc index 6994095..4340192 100644 --- a/recipes/libunwind/libunwind.inc +++ b/recipes/libunwind/libunwind.inc @@ -1,7 +1,8 @@ DESCRIPTION = "a portable and efficient C programming interface (API) to determine the call-chain of a program" HOMEPAGE = "http://www.nongnu.org/libunwind" LICENSE = "MIT" -INC_PR = "r1" +INC_PR = "r2" +DEPENDS = "gcc" SRC_URI = "http://download.savannah.nongnu.org/releases/${BPN}/${BPN}-${PV}.tar.gz;name=archive" -- 1.7.0.4 ^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: [PATCH] libunwind: force gcc to be built first 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 1 sibling, 0 replies; 15+ messages in thread From: Steffen Sledz @ 2010-09-30 8:49 UTC (permalink / raw) To: openembedded-devel Am 29.09.2010 18:17, schrieb Thilo Fromm: > libunwind causes cross gcc build to fail if libunwind is built first: > ... > This patch makes libunwind depend on gcc which resolves the build issue. Both > build nicely when gcc is built first. > > Signed-off-by: Thilo Fromm <t.fromm@dresearch.de> Acked-by: Steffen Sledz <sledz@dresearch.de> -- Steffen Sledz DResearch Digital Media Systems GmbH Otto-Schmirgal-Str.3, D-10319 Berlin, Germany Tel: +49 (30) 515932237 mailto:sledz@DResearch.DE Fax: +49 (30) 515932299 http://www.DResearch.DE Geschäftsführer: Dr. Michael Weber, Werner Mögle; Amtsgericht Berlin Charlottenburg; HRB 54412; Ust.-IDNr. DE169013825; WEEE Reg.-Nr. DE 85995642 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] libunwind: force gcc to be built first 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 1 sibling, 1 reply; 15+ messages in thread From: Frans Meulenbroeks @ 2010-09-30 10:21 UTC (permalink / raw) To: openembedded-devel 2010/9/29 Thilo Fromm <t.fromm@dresearch.de>: > libunwind causes cross gcc build to fail if libunwind is built first: > > ... > | arm-angstrom-linux-gnueabi-gcc -march=armv5te -mtune=arm926ej-s -mthumb-interwork -mno-thumb -march=armv5te -mtune=arm926ej-s -mthumb-interwork -mno-thumb -isystem/SCRATCH/maniac/oe-merge-test/OE/tmp.6/sysroots/armv5te-angstrom-linux-gnueabi/usr/include -g -Os -O2 -g -Os -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../.././gcc -I/SCRATCH/maniac/oe-merge-test/OE/tmp.6/work/armv5te-angstrom-linux-gnueabi/gcc-4.3.3-r17.1/gcc-4.3.3/libgcc -I/SCRATCH/maniac/oe-merge-test/OE/tmp.6/work/armv5te-angstrom-linux-gnueabi/gcc-4.3.3-r17.1/gcc-4.3.3/libgcc/. -I/SCRATCH/maniac/oe-merge-test/OE/tmp.6/work/armv5te-angstrom-linux-gnueabi/gcc-4.3.3-r17.1/gcc-4.3.3/libgcc/../gcc -I/SCRATCH/maniac/oe-merge-test/OE/tmp.6/work/armv5te-angstrom-linux-gnueabi/gcc-4.3.3-r17.1/gcc-4.3.3/libgcc/../include -DHAVE_CC_TLS -o _ucmpdi2_s.o -MT _ucmpdi2_s.o > \ > -MD -MP -MF _ucmpdi2_s.dep -DSHARED -DL_ucmpdi2 -c /SCRATCH/maniac/oe-merge-test/OE/tmp.6/work/armv5te-angstrom-linux-gnueabi/gcc-4.3.3-r17.1/gcc-4.3.3/libgcc/../gcc/libgcc2.c > | /SCRATCH/maniac/oe-merge-test/OE/tmp.6/work/armv5te-angstrom-linux-gnueabi/gcc-4.3.3-r17.1/gcc-4.3.3/libgcc/../gcc/config/arm/unwind-arm.c:40: error: expected ')' before '*' token > | /SCRATCH/maniac/oe-merge-test/OE/tmp.6/work/armv5te-angstrom-linux-gnueabi/gcc-4.3.3-r17.1/gcc-4.3.3/libgcc/../gcc/config/arm/unwind-arm.c:41: error: expected ')' before '*' token > | /SCRATCH/maniac/oe-merge-test/OE/tmp.6/work/armv5te-angstrom-linux-gnueabi/gcc-4.3.3-r17.1/gcc-4.3.3/libgcc/../gcc/config/arm/unwind-arm.c:42: error: expected ')' before '*' token > | /SCRATCH/maniac/oe-merge-test/OE/tmp.6/work/armv5te-angstrom-linux-gnueabi/gcc-4.3.3-r17.1/gcc-4.3.3/libgcc/../gcc/config/arm/unwind-arm.c:47: warning: data definition has no type or storage class > ... > > | /SCRATCH/maniac/oe-merge-test/OE/tmp.6/work/armv5te-angstrom-linux-gnueabi/gcc-4.3.3-r17.1/gcc-4.3.3/libgcc/../gcc/config/arm/pr-support.c:396: error: expected '=', ',', ';', 'asm' or '__attribute__' before '_Unwind_GetDataRelBase' > | /SCRATCH/maniac/oe-merge-test/OE/tmp.6/work/armv5te-angstrom-linux-gnueabi/gcc-4.3.3-r17.1/gcc-4.3.3/libgcc/../gcc/config/arm/pr-support.c:402: error: expected '=', ',', ';', 'asm' or '__attribute__' before '_Unwind_GetTextRelBase' > | make[2]: *** [unwind-arm.o] Error 1 > | make[2]: *** Waiting for unfinished jobs.... > | make[2]: *** [pr-support.o] Error 1 > ... > > | /SCRATCH/maniac/oe-merge-test/OE/tmp.6/work/armv5te-angstrom-linux-gnueabi/gcc-4.3.3-r17.1/gcc-4.3.3/libgcc/../gcc/unwind-c.c:212: error: 'lsda_header_info' has no member named 'LPStart' > | /SCRATCH/maniac/oe-merge-test/OE/tmp.6/work/armv5te-angstrom-linux-gnueabi/gcc-4.3.3-r17.1/gcc-4.3.3/libgcc/../gcc/unwind-c.c:214: error: 'lsda_header_info' has no member named 'action_table' > | /SCRATCH/maniac/oe-merge-test/OE/tmp.6/work/armv5te-angstrom-linux-gnueabi/gcc-4.3.3-r17.1/gcc-4.3.3/libgcc/../gcc/unwind-c.c:234: error: expected ')' before 'ue_header' > | /SCRATCH/maniac/oe-merge-test/OE/tmp.6/work/armv5te-angstrom-linux-gnueabi/gcc-4.3.3-r17.1/gcc-4.3.3/libgcc/../gcc/unwind-c.c:123: warning: unused parameter 'ue_header' > | make[2]: *** [unwind-c.o] Error 1 > | make[2]: Leaving directory `/SCRATCH/maniac/oe-merge-test/OE/tmp.6/work/armv5te-angstrom-linux-gnueabi/gcc-4.3.3-r17.1/gcc-4.3.3/build.arm-angstrom-linux-gnueabi.arm-angstrom-linux-gnueabi/arm-angstrom-linux-gnueabi/libgcc' > | make[1]: *** [all-target-libgcc] Error 2 > | make[1]: Leaving directory `/SCRATCH/maniac/oe-merge-test/OE/tmp.6/work/armv5te-angstrom-linux-gnueabi/gcc-4.3.3-r17.1/gcc-4.3.3/build.arm-angstrom-linux-gnueabi.arm-angstrom-linux-gnueabi' > | make: *** [all] Error 2 > | FATAL: oe_runmake failed > | ERROR: Function do_compile failed > NOTE: package gcc-4.3.3-r17.1: task do_compile: Failed > > 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. Now I feel that if someone does a bitbake libunwind; bitbake -cclean gcc; bitbake gcc things still fail. Btw what include files are we talking about? Frans. > > Signed-off-by: Thilo Fromm <t.fromm@dresearch.de> > --- > recipes/libunwind/libunwind.inc | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/recipes/libunwind/libunwind.inc b/recipes/libunwind/libunwind.inc > index 6994095..4340192 100644 > --- a/recipes/libunwind/libunwind.inc > +++ b/recipes/libunwind/libunwind.inc > @@ -1,7 +1,8 @@ > DESCRIPTION = "a portable and efficient C programming interface (API) to determine the call-chain of a program" > HOMEPAGE = "http://www.nongnu.org/libunwind" > LICENSE = "MIT" > -INC_PR = "r1" > +INC_PR = "r2" > +DEPENDS = "gcc" > > SRC_URI = "http://download.savannah.nongnu.org/releases/${BPN}/${BPN}-${PV}.tar.gz;name=archive" > > -- > 1.7.0.4 > > > _______________________________________________ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] libunwind: force gcc to be built first 2010-09-30 10:21 ` Frans Meulenbroeks @ 2010-09-30 10:47 ` Thilo Fromm 2010-09-30 11:30 ` Frans Meulenbroeks 0 siblings, 1 reply; 15+ messages in thread From: Thilo Fromm @ 2010-09-30 10:47 UTC (permalink / raw) To: openembedded-devel 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. > 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. > 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. 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] libunwind: force gcc to be built first 2010-09-30 10:47 ` Thilo Fromm @ 2010-09-30 11:30 ` Frans Meulenbroeks 2010-10-01 10:09 ` Thilo Fromm 0 siblings, 1 reply; 15+ messages in thread From: Frans Meulenbroeks @ 2010-09-30 11:30 UTC (permalink / raw) To: openembedded-devel 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 > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] libunwind: force gcc to be built first 2010-09-30 11:30 ` Frans Meulenbroeks @ 2010-10-01 10:09 ` Thilo Fromm 2010-10-01 17:16 ` Khem Raj 0 siblings, 1 reply; 15+ messages in thread From: Thilo Fromm @ 2010-10-01 10:09 UTC (permalink / raw) To: openembedded-devel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] libunwind: force gcc to be built first 2010-10-01 10:09 ` Thilo Fromm @ 2010-10-01 17:16 ` Khem Raj 2010-10-02 6:33 ` Frans Meulenbroeks 0 siblings, 1 reply; 15+ messages in thread From: Khem Raj @ 2010-10-01 17:16 UTC (permalink / raw) To: Thilo Fromm; +Cc: openembedded-devel On Fri, Oct 1, 2010 at 3:09 AM, Thilo Fromm <t.fromm@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@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 > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] libunwind: force gcc to be built first 2010-10-01 17:16 ` Khem Raj @ 2010-10-02 6:33 ` Frans Meulenbroeks 2010-10-04 8:08 ` Thilo Fromm 0 siblings, 1 reply; 15+ messages in thread From: Frans Meulenbroeks @ 2010-10-02 6:33 UTC (permalink / raw) To: openembedded-devel 2010/10/1 Khem Raj <raj.khem@gmail.com>: > On Fri, Oct 1, 2010 at 3:09 AM, Thilo Fromm <t.fromm@dresearch.de> wrote: >> >> 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. > Thanks for the analysis Khem. This is indeed more or less what I had expected. For me this patch gets a NAK as it does only masks the problvem in some cases but not really solves it. Frans. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] libunwind: force gcc to be built first 2010-10-02 6:33 ` Frans Meulenbroeks @ 2010-10-04 8:08 ` Thilo Fromm 2010-10-04 16:00 ` Khem Raj 0 siblings, 1 reply; 15+ messages in thread From: Thilo Fromm @ 2010-10-04 8:08 UTC (permalink / raw) To: openembedded-devel Hello Frans, >>> 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. >> > Thanks for the analysis Khem. > This is indeed more or less what I had expected. > > For me this patch gets a NAK as it does only masks the problvem in > some cases but not really solves it. You're right with this analysis; however, the patch enables Openembedded to be built *at all*. If you care less about whether you're able to actually build and if you have the time to wait until someone ventures deep into the gcc build and fixes the cause, then this is the way to go. For us, however, this patch is a valid workaround. It will make Openembedded work for us until the original issue is fixed. 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] libunwind: force gcc to be built first 2010-10-04 8:08 ` Thilo Fromm @ 2010-10-04 16:00 ` Khem Raj 2011-02-14 8:32 ` Steffen Sledz 0 siblings, 1 reply; 15+ messages in thread From: Khem Raj @ 2010-10-04 16:00 UTC (permalink / raw) To: openembedded-devel On Mon, Oct 4, 2010 at 1:08 AM, Thilo Fromm <t.fromm@dresearch.de> wrote: > Hello Frans, > >>>> 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. >>> >> Thanks for the analysis Khem. >> This is indeed more or less what I had expected. >> >> For me this patch gets a NAK as it does only masks the problvem in >> some cases but not really solves it. > > You're right with this analysis; however, the patch enables Openembedded to > be built *at all*. If you care less about whether you're able to actually > build and if you have the time to wait until someone ventures deep into the > gcc build and fixes the cause, then this is the way to go. > > For us, however, this patch is a valid workaround. It will make Openembedded > work for us until the original issue is fixed. I think we should try to fix it in right way. > > 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 > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] libunwind: force gcc to be built first 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 0 siblings, 2 replies; 15+ messages in thread From: Steffen Sledz @ 2011-02-14 8:32 UTC (permalink / raw) To: openembedded-devel; +Cc: Thilo Fromm Am 04.10.2010 18:00, schrieb Khem Raj: > On Mon, Oct 4, 2010 at 1:08 AM, Thilo Fromm <t.fromm@dresearch.de> wrote: >> Hello Frans, >> >>>>> 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. >>>> >>> Thanks for the analysis Khem. >>> This is indeed more or less what I had expected. >>> >>> For me this patch gets a NAK as it does only masks the problvem in >>> some cases but not really solves it. >> >> You're right with this analysis; however, the patch enables Openembedded to >> be built *at all*. If you care less about whether you're able to actually >> build and if you have the time to wait until someone ventures deep into the >> gcc build and fixes the cause, then this is the way to go. >> >> For us, however, this patch is a valid workaround. It will make Openembedded >> work for us until the original issue is fixed. > > I think we should try to fix it in right way. Ping! -- DResearch Fahrzeugelektronik GmbH Otto-Schmirgal-Str. 3, 10319 Berlin, Germany Tel: +49 30 515932-237 mailto:sledz@DResearch.de Fax: +49 30 515932-299 Geschäftsführer: Dr. Michael Weber, Werner Mögle; Amtsgericht Berlin Charlottenburg; HRB 130120 B; Ust.-IDNr. DE273952058 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] libunwind: force gcc to be built first 2011-02-14 8:32 ` Steffen Sledz @ 2011-02-14 17:27 ` Tom Rini 2011-02-14 17:58 ` Khem Raj 1 sibling, 0 replies; 15+ messages in thread From: Tom Rini @ 2011-02-14 17:27 UTC (permalink / raw) To: openembedded-devel On 02/14/2011 01:32 AM, Steffen Sledz wrote: > Am 04.10.2010 18:00, schrieb Khem Raj: >> On Mon, Oct 4, 2010 at 1:08 AM, Thilo Fromm<t.fromm@dresearch.de> wrote: >>> Hello Frans, >>> >>>>>> 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. >>>>> >>>> Thanks for the analysis Khem. >>>> This is indeed more or less what I had expected. >>>> >>>> For me this patch gets a NAK as it does only masks the problvem in >>>> some cases but not really solves it. >>> >>> You're right with this analysis; however, the patch enables Openembedded to >>> be built *at all*. If you care less about whether you're able to actually >>> build and if you have the time to wait until someone ventures deep into the >>> gcc build and fixes the cause, then this is the way to go. >>> >>> For us, however, this patch is a valid workaround. It will make Openembedded >>> work for us until the original issue is fixed. >> >> I think we should try to fix it in right way. > > Ping! Can you re-submit so it (a) hits patchwork again and (b) consolidate the what's and whys and so forth in the commit message, if needed? Thanks! -- Tom Rini Mentor Graphics Corporation ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] libunwind: force gcc to be built first 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 1 sibling, 1 reply; 15+ messages in thread From: Khem Raj @ 2011-02-14 17:58 UTC (permalink / raw) To: Steffen Sledz; +Cc: openembedded-devel On Mon, Feb 14, 2011 at 12:32 AM, Steffen Sledz <sledz@dresearch.de> wrote: > Am 04.10.2010 18:00, schrieb Khem Raj: >> On Mon, Oct 4, 2010 at 1:08 AM, Thilo Fromm <t.fromm@dresearch.de> wrote: >>> Hello Frans, >>> >>>>>> 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. >>>>> >>>> Thanks for the analysis Khem. >>>> This is indeed more or less what I had expected. >>>> >>>> For me this patch gets a NAK as it does only masks the problvem in >>>> some cases but not really solves it. >>> >>> You're right with this analysis; however, the patch enables Openembedded to >>> be built *at all*. If you care less about whether you're able to actually >>> build and if you have the time to wait until someone ventures deep into the >>> gcc build and fixes the cause, then this is the way to go. >>> >>> For us, however, this patch is a valid workaround. It will make Openembedded >>> work for us until the original issue is fixed. >> >> I think we should try to fix it in right way. > > Ping! I think this patch does not fix the problem but hides it. It will not be worth to get it upstream > > -- > DResearch Fahrzeugelektronik GmbH > Otto-Schmirgal-Str. 3, 10319 Berlin, Germany > Tel: +49 30 515932-237 mailto:sledz@DResearch.de > Fax: +49 30 515932-299 > Geschäftsführer: Dr. Michael Weber, Werner Mögle; > Amtsgericht Berlin Charlottenburg; HRB 130120 B; > Ust.-IDNr. DE273952058 > > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] libunwind: force gcc to be built first 2011-02-14 17:58 ` Khem Raj @ 2011-02-14 19:10 ` Sledz, Steffen 2011-02-25 8:51 ` Steffen Sledz 0 siblings, 1 reply; 15+ messages in thread From: Sledz, Steffen @ 2011-02-14 19:10 UTC (permalink / raw) To: Khem Raj; +Cc: openembedded-devel Am 14.02.2011 18:58, schrieb Khem Raj: > On Mon, Feb 14, 2011 at 12:32 AM, Steffen Sledz <sledz@dresearch.de> wrote: >> Am 04.10.2010 18:00, schrieb Khem Raj: >>> On Mon, Oct 4, 2010 at 1:08 AM, Thilo Fromm <t.fromm@dresearch.de> wrote: >>>> Hello Frans, >>>> >>>>>>> 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. >>>>>> >>>>> Thanks for the analysis Khem. >>>>> This is indeed more or less what I had expected. >>>>> >>>>> For me this patch gets a NAK as it does only masks the problvem in >>>>> some cases but not really solves it. >>>> >>>> You're right with this analysis; however, the patch enables Openembedded to >>>> be built *at all*. If you care less about whether you're able to actually >>>> build and if you have the time to wait until someone ventures deep into the >>>> gcc build and fixes the cause, then this is the way to go. >>>> >>>> For us, however, this patch is a valid workaround. It will make Openembedded >>>> work for us until the original issue is fixed. >>> >>> I think we should try to fix it in right way. >> >> Ping! > > I think this patch does not fix the problem but hides it. It will not > be worth to get it upstream That's right. I read your comment from october 1st that you try to fix this "in the right way" by fixing "the gcc build to not look into standard sysroot/usr/include but prefer the local unwind.h when its using internal libunwind". Steffen -- DResearch Fahrzeugelektronik GmbH Otto-Schmirgal-Str. 3, 10319 Berlin, Germany Tel: +49 30 515932-237 mailto:sledz@DResearch.de Fax: +49 30 515932-299 Geschäftsführer: Dr. Michael Weber, Werner Mögle; Amtsgericht Berlin Charlottenburg; HRB 130120 B; Ust.-IDNr. DE273952058 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] libunwind: force gcc to be built first 2011-02-14 19:10 ` Sledz, Steffen @ 2011-02-25 8:51 ` Steffen Sledz 0 siblings, 0 replies; 15+ messages in thread From: Steffen Sledz @ 2011-02-25 8:51 UTC (permalink / raw) To: openembedded-devel Am 14.02.2011 20:10, schrieb Sledz, Steffen: > Am 14.02.2011 18:58, schrieb Khem Raj: >> On Mon, Feb 14, 2011 at 12:32 AM, Steffen Sledz <sledz@dresearch.de> wrote: >>> Am 04.10.2010 18:00, schrieb Khem Raj: >>>> On Mon, Oct 4, 2010 at 1:08 AM, Thilo Fromm <t.fromm@dresearch.de> wrote: >>>>> Hello Frans, >>>>> >>>>>>>> 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. >>>>>>> >>>>>> Thanks for the analysis Khem. >>>>>> This is indeed more or less what I had expected. >>>>>> >>>>>> For me this patch gets a NAK as it does only masks the problvem in >>>>>> some cases but not really solves it. >>>>> >>>>> You're right with this analysis; however, the patch enables Openembedded to >>>>> be built *at all*. If you care less about whether you're able to actually >>>>> build and if you have the time to wait until someone ventures deep into the >>>>> gcc build and fixes the cause, then this is the way to go. >>>>> >>>>> For us, however, this patch is a valid workaround. It will make Openembedded >>>>> work for us until the original issue is fixed. >>>> >>>> I think we should try to fix it in right way. >>> >>> Ping! >> >> I think this patch does not fix the problem but hides it. It will not >> be worth to get it upstream > > That's right. > > I read your comment from october 1st that you try to fix this "in the right way" by fixing "the gcc build to not look into standard sysroot/usr/include but prefer the local unwind.h when its using internal libunwind". Ping! -- DResearch Fahrzeugelektronik GmbH Otto-Schmirgal-Str. 3, 10319 Berlin, Germany Tel: +49 30 515932-237 mailto:sledz@DResearch.de Fax: +49 30 515932-299 Geschäftsführer: Dr. Michael Weber, Werner Mögle; Amtsgericht Berlin Charlottenburg; HRB 130120 B; Ust.-IDNr. DE273952058 ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2011-02-25 8:52 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 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
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.