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

Phil Blundell philb at gnu.org
Wed Mar 16 14:06:52 UTC 2011


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.  Obviously you'd lose debuggability but that might
or might not be a problem for your particular use case.

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

p.





More information about the Openembedded-devel mailing list