[PATCH] libunwind: force gcc to be built first

[PATCH] libunwind: force gcc to be built first

[Thilo Fromm]

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

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

[Steffen Sledz]

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

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

[Frans Meulenbroeks]

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
>

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

[Thilo Fromm]

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

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

[Frans Meulenbroeks]

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
>

Re: [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@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

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

[Khem Raj]

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
>

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

[Frans Meulenbroeks]

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.

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

[Thilo Fromm]

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

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

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

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

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

[Steffen Sledz]

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

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

[Tom Rini]

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

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

[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


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

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

[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".

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

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

[Steffen Sledz]

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