diff mbox

Analysis of autobuild failures 18-19/11

Message ID 20161121112128.GP27313@waldemar-brodkorb.de
State Not Applicable
Headers show

Commit Message

Waldemar Brodkorb Nov. 21, 2016, 11:21 a.m. UTC
Hi,
Arnout Vandecappelle wrote,

>  Hi all,
> 
>  Here's an analysis of autobuild failures. It looks a bit different from what
> Thomas usually sends because I based it on the website rather than the mail. I
> eliminated the ones that are already fixed in git, and also the powerpc64le
> failures that are due to libtool.m4.
> 
>  I'm not putting the people from get-developers in Cc, because they already get
> these mails.
> 
> http://autobuild.buildroot.net/results/d47fa41aa860d82471b83ac90967d3a3dacd8611
> m68k / 5208	lcdapi-v0.10	uclibc	static
> 
> > /tmp/cc6S5lwR.s: Assembler messages:
> > /tmp/cc6S5lwR.s: Internal error, aborting at dw2gencfi.c:214 in emit_expr_encoded
> > Please report this bug.
> > Makefile:784: recipe for target 'lcdapi/api/liblcdapi_la-LCDHorizontalBar.lo' failed
> 
>  ICE... Waldemar?

This could be avoided by using something like the following (example
for libasplib):

Unfortunately libasplib cmake infrastructure ignores my
CMAKE_CXX_FLAGS. 

The m68k/coldfire uclinux seems to have some limitation regarding
CFI assembly generation, as elf2flt lacks some features.
See here for the comment in the code of GNU as:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gas/config/tc-m68k.h;h=30ca2cb35e0b00048c52bda0dc04ae0cdef5cc3a;hb=HEAD#l180

With gcc -fno-dwarf2-cfi-asm we can disable the CFI generation and
at least fix the compile errors for those packages.
 
Not sure if it will break some exception handling in C++ code or if
it only disables the ability to debug the code.
 
> http://autobuild.buildroot.net/results/4fb4353bce614b64b30b05d06831e0d0f38a48dd
> bfin / bf532	libarchive-3.2.1	uclibc	static
> 
> > ./.libs/libarchive.a(archive_random.o): In function `_archive_random':
> > libarchive/archive_random.c:(.text+0x158): undefined reference to `_pthread_mutex_lock'
> > libarchive/archive_random.c:(.text+0x20a): undefined reference to `_pthread_mutex_unlock'
> 
>  pthread static linking problem with the ADI toolchain. Probably solved with
> current uClibc-ng.

Yes, absolutely. May be disable for this toolchain, like Thomas did
for some other package recently.
 
best regards
 Waldemar

Comments

Arnout Vandecappelle Nov. 21, 2016, 11:40 p.m. UTC | #1
On 21-11-16 12:21, Waldemar Brodkorb wrote:
> Hi,
> Arnout Vandecappelle wrote,
> 
>>  Hi all,
>>
>>  Here's an analysis of autobuild failures. It looks a bit different from what
>> Thomas usually sends because I based it on the website rather than the mail. I
>> eliminated the ones that are already fixed in git, and also the powerpc64le
>> failures that are due to libtool.m4.
>>
>>  I'm not putting the people from get-developers in Cc, because they already get
>> these mails.
>>
>> http://autobuild.buildroot.net/results/d47fa41aa860d82471b83ac90967d3a3dacd8611
>> m68k / 5208	lcdapi-v0.10	uclibc	static
>>
>>> /tmp/cc6S5lwR.s: Assembler messages:
>>> /tmp/cc6S5lwR.s: Internal error, aborting at dw2gencfi.c:214 in emit_expr_encoded
>>> Please report this bug.
>>> Makefile:784: recipe for target 'lcdapi/api/liblcdapi_la-LCDHorizontalBar.lo' failed
>>
>>  ICE... Waldemar?
> 
> This could be avoided by using something like the following (example
> for libasplib):
> diff --git a/package/libasplib/libasplib.mk
> b/package/libasplib/libasplib.mk
> index 41aeaeb..b09d739 100644
> --- a/package/libasplib/libasplib.mk
> +++ b/package/libasplib/libasplib.mk
> @@ -10,4 +10,11 @@ LIBASPLIB_LICENSE = GPLv3+
>  LIBASPLIB_LICENSE_FILES = LICENSE
>  LIBASPLIB_INSTALL_STAGING = YES
>  
> +# Internal error, aborting at dw2gencfi.c:214 in emit_expr_encoded
> +ifeq ($(BR2_m68k_cf),y)
> +LIBASPLIB_CXXFLAGS += -fno-dwarf2-cfi-asm
> +endif
> +
> +LIBASPLIB_CONF_OPTS += -DCMAKE_CXX_FLAGS="$(TARGET_CXXFLAGS) $(LIBASPLIB_CXXFLAGS)"
> +
>  $(eval $(cmake-package))
> 
> Unfortunately libasplib cmake infrastructure ignores my
> CMAKE_CXX_FLAGS. 
> 
> The m68k/coldfire uclinux seems to have some limitation regarding
> CFI assembly generation, as elf2flt lacks some features.
> See here for the comment in the code of GNU as:
> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gas/config/tc-m68k.h;h=30ca2cb35e0b00048c52bda0dc04ae0cdef5cc3a;hb=HEAD#l180
> 
> With gcc -fno-dwarf2-cfi-asm we can disable the CFI generation and
> at least fix the compile errors for those packages.
>  
> Not sure if it will break some exception handling in C++ code or if
> it only disables the ability to debug the code.

 If it doesn't break things (and you can do runtime test, right?), maybe we
should just pass -fno-dwarf2-cfi-asm in the wrapper for coldfire?

 Regards,
 Arnout
Waldemar Brodkorb Nov. 23, 2016, 11:37 a.m. UTC | #2
Hi Arnout,
Arnout Vandecappelle wrote,

> On 21-11-16 12:21, Waldemar Brodkorb wrote:
> > Hi,
> > Arnout Vandecappelle wrote,
> > 
> >>  Hi all,
> >>
> >>  Here's an analysis of autobuild failures. It looks a bit different from what
> >> Thomas usually sends because I based it on the website rather than the mail. I
> >> eliminated the ones that are already fixed in git, and also the powerpc64le
> >> failures that are due to libtool.m4.
> >>
> >>  I'm not putting the people from get-developers in Cc, because they already get
> >> these mails.
> >>
> >> http://autobuild.buildroot.net/results/d47fa41aa860d82471b83ac90967d3a3dacd8611
> >> m68k / 5208	lcdapi-v0.10	uclibc	static
> >>
> >>> /tmp/cc6S5lwR.s: Assembler messages:
> >>> /tmp/cc6S5lwR.s: Internal error, aborting at dw2gencfi.c:214 in emit_expr_encoded
> >>> Please report this bug.
> >>> Makefile:784: recipe for target 'lcdapi/api/liblcdapi_la-LCDHorizontalBar.lo' failed
> >>
> >>  ICE... Waldemar?
> > 
> > This could be avoided by using something like the following (example
> > for libasplib):
> > diff --git a/package/libasplib/libasplib.mk
> > b/package/libasplib/libasplib.mk
> > index 41aeaeb..b09d739 100644
> > --- a/package/libasplib/libasplib.mk
> > +++ b/package/libasplib/libasplib.mk
> > @@ -10,4 +10,11 @@ LIBASPLIB_LICENSE = GPLv3+
> >  LIBASPLIB_LICENSE_FILES = LICENSE
> >  LIBASPLIB_INSTALL_STAGING = YES
> >  
> > +# Internal error, aborting at dw2gencfi.c:214 in emit_expr_encoded
> > +ifeq ($(BR2_m68k_cf),y)
> > +LIBASPLIB_CXXFLAGS += -fno-dwarf2-cfi-asm
> > +endif
> > +
> > +LIBASPLIB_CONF_OPTS += -DCMAKE_CXX_FLAGS="$(TARGET_CXXFLAGS) $(LIBASPLIB_CXXFLAGS)"
> > +
> >  $(eval $(cmake-package))
> > 
> > Unfortunately libasplib cmake infrastructure ignores my
> > CMAKE_CXX_FLAGS. 
> > 
> > The m68k/coldfire uclinux seems to have some limitation regarding
> > CFI assembly generation, as elf2flt lacks some features.
> > See here for the comment in the code of GNU as:
> > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gas/config/tc-m68k.h;h=30ca2cb35e0b00048c52bda0dc04ae0cdef5cc3a;hb=HEAD#l180
> > 
> > With gcc -fno-dwarf2-cfi-asm we can disable the CFI generation and
> > at least fix the compile errors for those packages.
> >  
> > Not sure if it will break some exception handling in C++ code or if
> > it only disables the ability to debug the code.
> 
>  If it doesn't break things (and you can do runtime test, right?), maybe we
> should just pass -fno-dwarf2-cfi-asm in the wrapper for coldfire?

I don't know the internals of the wrapper, could you suggest a
patch, then I can do some testing with either Qemu or some real
board.

best regards
 Waldemar
diff mbox

Patch

diff --git a/package/libasplib/libasplib.mk
b/package/libasplib/libasplib.mk
index 41aeaeb..b09d739 100644
--- a/package/libasplib/libasplib.mk
+++ b/package/libasplib/libasplib.mk
@@ -10,4 +10,11 @@  LIBASPLIB_LICENSE = GPLv3+
 LIBASPLIB_LICENSE_FILES = LICENSE
 LIBASPLIB_INSTALL_STAGING = YES
 
+# Internal error, aborting at dw2gencfi.c:214 in emit_expr_encoded
+ifeq ($(BR2_m68k_cf),y)
+LIBASPLIB_CXXFLAGS += -fno-dwarf2-cfi-asm
+endif
+
+LIBASPLIB_CONF_OPTS += -DCMAKE_CXX_FLAGS="$(TARGET_CXXFLAGS) $(LIBASPLIB_CXXFLAGS)"
+
 $(eval $(cmake-package))