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

Paul Menzel paulepanter at users.sourceforge.net
Wed Mar 16 13:39:15 UTC 2011


Am Mittwoch, den 16.03.2011, 09:56 +0000 schrieb Phil Blundell:
> On Wed, 2011-03-16 at 09:52 +0100, Paul Menzel wrote:
> > I am sorry. But I could not find an error message anywhere in
> > `log.do_compile`. Please find the log file attached.
> 
> One of libtool's less endearing features is that it runs the compiler
> for shared objects with errors directed to /dev/null.  I guess this is
> to avoid getting repeated warnings for objects that are compiled both
> shared and nonshared, but it does make it more tedious to debug this
> kind of crash.

Thank you for the explanation and the following advise.

> Anyway, the line in question is this one from your log file:
> 
> arm-oe-linux-uclibceabi-libtool: compile:  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 >/dev/null 2>&1
> 
> If you run that compile command manually with the ">/dev/null 2>&1" bit
> removed then you should be able to see the errors.  Given that it's
> apparently happening only with -fPIC enabled I would suspect that it's
> an ice of some kind, rather than being uclibc's fault directly, but once
> we have the error message it should be fairly obvious what's gone wrong.

        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:

I am wondering if the latest GCC 4.5 changes are causing this, but as
always this is just an uneducated guess.

        commit 21ce5641f8c993aefeefd8febd210f41dbf1d442
        Author: Khem Raj <raj.khem at gmail.com>
        Date:   Fri Mar 11 15:47:23 2011 -0800
        
            gcc-4.5: Fix ICE on i586
            
            Upgrade to latest svnrev
            Get new linaro patches
            Delete patches that are not applied
            
            Signed-off-by: Khem Raj <raj.khem at gmail.com>
            Tested-by: Yuri Bushmelev <jay4mail at gmail.com>

Searching for the error message just returned a bug report for GCC 3.4 [1].


Thanks,

Paul


[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10695
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20110316/f24c7986/attachment-0002.sig>


More information about the Openembedded-devel mailing list