Re: minimal-uclibc: gnutls-2.10.4-r11.0: task compile fails with `make[4]: *** [coding.lo] Error 1`

From: Khem Raj <raj.khem@gmail.com>
To: openembedded-devel@lists.openembedded.org
Subject: Re: minimal-uclibc: gnutls-2.10.4-r11.0: task compile fails with `make[4]: *** [coding.lo] Error 1`
Date: Wed, 16 Mar 2011 10:59:33 -0700	[thread overview]
Message-ID: <4D80FA85.7030903@gmail.com> (raw)
In-Reply-To: <1300287990.3840.85.camel@mattotaupa>

On 3/16/2011 8:06 AM, Paul Menzel wrote:
> Am Mittwoch, den 16.03.2011, 14:06 +0000 schrieb Phil Blundell:
>> On Wed, 2011-03-16 at 14:39 +0100, Paul Menzel wrote:
>>>          arm-oe-linux-uclibceabi-gcc -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -mthumb-interwork -mno-thumb --sysroot=/oe/build-minimal-uclibc/minimal-uclibc-dev/sysroots/armv7a-oe-linux-uclibceabi -DHAVE_CONFIG_H -I. -I.. -DASN1_BUILDING -I./../gl -I./../gl -I./.. -fexpensive-optimizations -fomit-frame-pointer -frename-registers -Os -pipe -g -MT coding.lo -MD -MP -MF .deps/coding.Tpo -c coding.c -o coding.o
>>>          coding.c: In function 'asn1_length_der':
>>>          coding.c:101:1: internal compiler error: in dwarf2out_frame_debug_expr, at dwarf2out.c:2221
>>>          Please submit a full bug report,
>>>          with preprocessed source if appropriate.
>>>          See<http://gcc.gnu.org/bugs.html>  for instructions.
>>>          {standard input}: Assembler messages:
>>
>> > From the looks of the error, you could probably work around the crash by
>> compiling without -g.
>
> Thanks, that worked.
>
>> Obviously you'd lose debuggability but that might or might not be a
>> problem for your particular use case.
>
> Well, I am just build testing.
>
>>> I am wondering if the latest GCC 4.5 changes are causing this, but as
>>> always this is just an uneducated guess.
>>
>> Could be.  Or it's possible that the bug has been latent for a long time
>> and has just been tickled by a recent change to CFLAGS.  I think the
>> inclusion of -g in the default opts is a relatively recent innovation.
>
> I think it worked before last Friday, i. e., before the GCC 4.5 updates.

Yes and the fix was to address exact same problem but reported in 
another recipe. So it fixed things but partially. Let me try to poke 
around a bit

>
>> You could bisect the recent changes if you want but, unless you want to
>> debug this for yourself, the best way to proceed is probably to follow
>> the directions in the error message and submit a bug report to upstream
>> GCC.
>
> I will see, if or when I will get to that and report back.
>
>
> Thanks,
>
> Paul
>
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel