Debian Bug report logs - #476302
iceweasel: ftbfs on armel: temporary object destruction order

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Jon Dowland <jon+bts@alcopop.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: iceweasel: ftbfs on armel: temporary object destruction order

Date: Fri, 04 Apr 2008 19:04:08 +0100

Package: iceweasel
Version: 3.0~b5-1
Severity: normal

...
checking for unwind.h... yes
checking for _Unwind_Backtrace... yes
checking for gcc -pipe support... yes
checking whether compiler supports -Wno-long-long... yes
checking whether C compiler supports -fprofile-generate... yes
checking for correct temporary object destruction order... no
configure: error: Your compiler does not follow the C++ specification 
for temporary object destruction order.
make: *** [config.status] Error 1
dpkg-buildpackage: failure: debian/rules build gave error exit status 2



-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: armel (armv5tel)

Kernel: Linux 2.6.24-1-iop32x
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash

Message #10 received at 474281@bugs.debian.org (full text, mbox, reply):

From: Jon Dowland <jon+bts@alcopop.org>

To: 474281@bugs.debian.org

Subject: Re: Bug#474281: Acknowledgement (iceweasel: ftbfs on armel: temporary object destruction order)

Date: Fri, 4 Apr 2008 19:22:07 +0100

[Message part 1 (text/plain, inline)]

config.log attached.

ii  g++                             4:4.3.0-3                  The GNU
ii  g++-4.3                         4.3.0-2                    The GNU
ii  gcc                             4:4.3.0-3                  The GNU C
ii  gcc-4.2-base                    4.2.3-3                    The GNU
ii  gcc-4.3                         4.3.0-2                    The GNU C
ii  gcc-4.3-base                    4.3.0-2                    The GNU

[config.log (text/plain, attachment)]

Message #15 received at 474281@bugs.debian.org (full text, mbox, reply):

From: Jon Dowland <jon@alcopop.org>

To: control@bugs.debian.org

Cc: 474281@bugs.debian.org

Subject: severity of 474281 is normal

Date: Fri, 04 Apr 2008 19:29:16 +0100

# Automatically generated email from bts, devscripts version 2.10.20
# I forgot armel isn't a released arch yet
severity 474281 normal

Message #22 received at 474281@bugs.debian.org (full text, mbox, reply):

From: Mike Hommey <mh@glandium.org>

To: Jon Dowland <jon+bts@alcopop.org>, 474281@bugs.debian.org

Subject: Re: Bug#474281: Acknowledgement (iceweasel: ftbfs on armel: temporary object destruction order)

Date: Fri, 4 Apr 2008 21:31:27 +0200

On Fri, Apr 04, 2008 at 07:22:07PM +0100, Jon Dowland wrote:
> configure:17706: c++ -o conftest  -fno-strict-aliasing -fshort-wchar -pthread -pipe   -lpthread -Wl,--as-needed conftest.C -ldl -lm  1>&5
> /usr/bin/ld: ERROR: /tmp/ccef8aU1.o: Conflicting definitions of wchar_t

WTF?!? There's not even wchar_t in the source

> /usr/bin/ld: failed to merge target specific data of file /tmp/ccef8aU1.o
> collect2: ld returned 1 exit status
> configure: failed program was:
> #line 17686 "configure"
> #include "confdefs.h"
>  class A {
>              public:  A(int& x) : mValue(x) {}
>                       ~A() { mValue--; }
>                       operator char**() { return 0; }
>              private:  int& mValue;
>              };
>              void func(char **arg) {}
>              int m=2;
>              void test() {
>                   func(A(m));
>                   if (m==1) m = 0;
>              }
>              int main() {
>                  test();
>                  return(m);
>              }
>              

Message #27 received at 474281@bugs.debian.org (full text, mbox, reply):

From: Jon Dowland <jon+bts@alcopop.org>

To: Mike Hommey <mh@glandium.org>

Cc: 474281@bugs.debian.org

Subject: Re: Bug#474281: Acknowledgement (iceweasel: ftbfs on armel: temporary object destruction order)

Date: Fri, 4 Apr 2008 20:50:31 +0100

On Fri, Apr 04, 2008 at 09:31:27PM +0200, Mike Hommey wrote:
> On Fri, Apr 04, 2008 at 07:22:07PM +0100, Jon Dowland wrote:
> > configure:17706: c++ -o conftest  -fno-strict-aliasing -fshort-wchar -pthread -pipe   -lpthread -Wl,--as-needed conftest.C -ldl -lm  1>&5
> > /usr/bin/ld: ERROR: /tmp/ccef8aU1.o: Conflicting definitions of wchar_t
> 
> WTF?!? There's not even wchar_t in the source

I know bugger all about c++ but I'm plodding on, since there's no
experimental buildd for armel yet.

19:32 < suihkulokki> Jon: The problem is -fshort-wchar option, you would
need to hack the configure scripts to not enable it

I'm just trying to disable that chunk of stuff in configure.in and
regenerate the makefiles, then try again.


-- 
Jon Dowland

Message #32 received at 474281@bugs.debian.org (full text, mbox, reply):

From: Mike Hommey <mh@glandium.org>

To: Jon Dowland <jon+bts@alcopop.org>

Cc: 474281@bugs.debian.org

Subject: Re: Bug#474281: Acknowledgement (iceweasel: ftbfs on armel: temporary object destruction order)

Date: Fri, 4 Apr 2008 22:08:28 +0200

On Fri, Apr 04, 2008 at 08:50:31PM +0100, Jon Dowland wrote:
> On Fri, Apr 04, 2008 at 09:31:27PM +0200, Mike Hommey wrote:
> > On Fri, Apr 04, 2008 at 07:22:07PM +0100, Jon Dowland wrote:
> > > configure:17706: c++ -o conftest  -fno-strict-aliasing -fshort-wchar -pthread -pipe   -lpthread -Wl,--as-needed conftest.C -ldl -lm  1>&5
> > > /usr/bin/ld: ERROR: /tmp/ccef8aU1.o: Conflicting definitions of wchar_t
> > 
> > WTF?!? There's not even wchar_t in the source
> 
> I know bugger all about c++ but I'm plodding on, since there's no
> experimental buildd for armel yet.
> 
> 19:32 < suihkulokki> Jon: The problem is -fshort-wchar option, you would
> need to hack the configure scripts to not enable it
> 
> I'm just trying to disable that chunk of stuff in configure.in and
> regenerate the makefiles, then try again.

On the other hand, it builds this correctly:
configure:8114: checking for compiler -fshort-wchar option
configure:8128: c++ -c  -fno-strict-aliasing -fshort-wchar   conftest.C 1>&5

This being generated by the following configure.in snippet:
        [AC_TRY_COMPILE([#include <stddef.h>
                         $configure_static_assert_macros],
                        [CONFIGURE_STATIC_ASSERT(sizeof(wchar_t) == 2);
                         CONFIGURE_STATIC_ASSERT((wchar_t)-1 > (wchar_t) 0)],
                        ac_cv_have_usable_wchar_option_v2="yes",
                        ac_cv_have_usable_wchar_option_v2="no")])

This snippet is responsible for the addition of -fshort-wchar in the CXX_FLAGS in
what is failing for you.

Mike

Message #39 received at 474281@bugs.debian.org (full text, mbox, reply):

From: Mike Hommey <mh@glandium.org>

To: Jon Dowland <jon+bts@alcopop.org>

Cc: 474281@bugs.debian.org

Subject: Re: Bug#474281: Acknowledgement (iceweasel: ftbfs on armel: temporary object destruction order)

Date: Fri, 4 Apr 2008 22:23:03 +0200

On Fri, Apr 04, 2008 at 10:08:28PM +0200, Mike Hommey wrote:
> On Fri, Apr 04, 2008 at 08:50:31PM +0100, Jon Dowland wrote:
> > On Fri, Apr 04, 2008 at 09:31:27PM +0200, Mike Hommey wrote:
> > > On Fri, Apr 04, 2008 at 07:22:07PM +0100, Jon Dowland wrote:
> > > > configure:17706: c++ -o conftest  -fno-strict-aliasing -fshort-wchar -pthread -pipe   -lpthread -Wl,--as-needed conftest.C -ldl -lm  1>&5
> > > > /usr/bin/ld: ERROR: /tmp/ccef8aU1.o: Conflicting definitions of wchar_t
> > > 
> > > WTF?!? There's not even wchar_t in the source
> > 
> > I know bugger all about c++ but I'm plodding on, since there's no
> > experimental buildd for armel yet.
> > 
> > 19:32 < suihkulokki> Jon: The problem is -fshort-wchar option, you would
> > need to hack the configure scripts to not enable it
> > 
> > I'm just trying to disable that chunk of stuff in configure.in and
> > regenerate the makefiles, then try again.
> 
> On the other hand, it builds this correctly:
> configure:8114: checking for compiler -fshort-wchar option
> configure:8128: c++ -c  -fno-strict-aliasing -fshort-wchar   conftest.C 1>&5
> 
> This being generated by the following configure.in snippet:
>         [AC_TRY_COMPILE([#include <stddef.h>
>                          $configure_static_assert_macros],
>                         [CONFIGURE_STATIC_ASSERT(sizeof(wchar_t) == 2);
>                          CONFIGURE_STATIC_ASSERT((wchar_t)-1 > (wchar_t) 0)],
>                         ac_cv_have_usable_wchar_option_v2="yes",
>                         ac_cv_have_usable_wchar_option_v2="no")])
> 
> This snippet is responsible for the addition of -fshort-wchar in the CXX_FLAGS in
> what is failing for you.

And both tests have not changed for a while, and xulrunner build fine on
armel in unstable [1]

Could you try to use the same toolchain as when xulrunner was built ?
i.e. gcc-4.2_4.2.3-2 g++-4.2_4.2.3-2 binutils_2.18.1~cvs20080103-1

Mike

1.  http://buildd.debian.org/fetch.cgi?pkg=xulrunner;ver=1.8.1.12-5;arch=armel;stamp=1206621388

Message #44 received at 474281@bugs.debian.org (full text, mbox, reply):

From: Riku Voipio <riku.voipio@iki.fi>

To: Mike Hommey <mh@glandium.org>

Cc: Jon Dowland <jon+bts@alcopop.org>, 474281@bugs.debian.org

Subject: Re: Bug#474281: Acknowledgement (iceweasel: ftbfs on armel: temporary object destruction order)

Date: Sat, 5 Apr 2008 00:13:45 +0300

On Fri, Apr 04, 2008 at 07:22:07PM +0100, Jon Dowland wrote:
> configure:17706: c++ -o conftest  -fno-strict-aliasing -fshort-wchar -pthread -pipe   -lpthread -Wl,--as-needed conftest.C -ldl -lm  1>&5
> /usr/bin/ld: ERROR: /tmp/ccef8aU1.o: Conflicting definitions of wchar_t

Notice the error happens at linking time

> On the other hand, it builds this correctly:
> configure:8114: checking for compiler -fshort-wchar option
> configure:8128: c++ -c  -fno-strict-aliasing -fshort-wchar   conftest.C 1>&5

...and 'c++ -c' specifically does _not_ link.

$ cat test.c
#include <stddef.h>
#include <wchar.h>

int main() {
; return 0; }
all6500-2:~/icew
$ c++ -c -fno-strict-aliasing -fshort-wchar test.c
$ echo $?
0
$ c++  -fno-strict-aliasing -fshort-wchar test.c
/usr/bin/ld: ERROR: /tmp/ccKVwN1s.o: Conflicting definitions of wchar_t
/usr/bin/ld: failed to merge target specific data of file
/tmp/ccKVwN1s.o
collect2: ld returned 1 exit status

> And both tests have not changed for a while, and xulrunner build fine on
> armel in unstable [1]

FWIW xulrunner/iceweasel based on FF 2.0 does not work (even if it
compiles) on armel. That's why we are looking at getting FF3.0
compiled. The nokia internet tablets are based on armel and and
have browser based on FF3.0 alpha, so it would seem more feasible
to get FF3.0 working than backporting the support to 2.0..

> Could you try to use the same toolchain as when xulrunner was built ?
> i.e. gcc-4.2_4.2.3-2 g++-4.2_4.2.3-2 binutils_2.18.1~cvs20080103-1

A quick test confirms, test.c compiles fine with g++-4.2, but fails with
g++-4.3.

Message #49 received at 474281@bugs.debian.org (full text, mbox, reply):

From: Mike Hommey <mh@glandium.org>

To: Riku Voipio <riku.voipio@iki.fi>, 474281@bugs.debian.org

Cc: Jon Dowland <jon+bts@alcopop.org>

Subject: Re: Bug#474281: Acknowledgement (iceweasel: ftbfs on armel: temporary object destruction order)

Date: Sat, 5 Apr 2008 10:25:45 +0200

On Sat, Apr 05, 2008 at 12:13:45AM +0300, Riku Voipio wrote:
> On Fri, Apr 04, 2008 at 07:22:07PM +0100, Jon Dowland wrote:
> > configure:17706: c++ -o conftest  -fno-strict-aliasing -fshort-wchar -pthread -pipe   -lpthread -Wl,--as-needed conftest.C -ldl -lm  1>&5
> > /usr/bin/ld: ERROR: /tmp/ccef8aU1.o: Conflicting definitions of wchar_t
> 
> Notice the error happens at linking time
> 
> > On the other hand, it builds this correctly:
> > configure:8114: checking for compiler -fshort-wchar option
> > configure:8128: c++ -c  -fno-strict-aliasing -fshort-wchar   conftest.C 1>&5
> 
> ...and 'c++ -c' specifically does _not_ link.
> 
> $ cat test.c
> #include <stddef.h>
> #include <wchar.h>
> 
> int main() {
> ; return 0; }
> all6500-2:~/icew
> $ c++ -c -fno-strict-aliasing -fshort-wchar test.c
> $ echo $?
> 0
> $ c++  -fno-strict-aliasing -fshort-wchar test.c
> /usr/bin/ld: ERROR: /tmp/ccKVwN1s.o: Conflicting definitions of wchar_t
> /usr/bin/ld: failed to merge target specific data of file
> /tmp/ccKVwN1s.o
> collect2: ld returned 1 exit status
> 
> > And both tests have not changed for a while, and xulrunner build fine on
> > armel in unstable [1]
> 
> FWIW xulrunner/iceweasel based on FF 2.0 does not work (even if it
> compiles) on armel. That's why we are looking at getting FF3.0
> compiled. The nokia internet tablets are based on armel and and
> have browser based on FF3.0 alpha, so it would seem more feasible
> to get FF3.0 working than backporting the support to 2.0..

It would still be nice to get the bug reports, especially considering
iceape and icedove, which i assume both build fine too, will more than
probably ship in 2.0 based versions in lenny.

> > Could you try to use the same toolchain as when xulrunner was built ?
> > i.e. gcc-4.2_4.2.3-2 g++-4.2_4.2.3-2 binutils_2.18.1~cvs20080103-1
> 
> A quick test confirms, test.c compiles fine with g++-4.2, but fails with
> g++-4.3.

Seems like a candidate for a gcc regression :-/

Mike

Message #54 received at 474281@bugs.debian.org (full text, mbox, reply):

From: Riku Voipio <riku.voipio@iki.fi>

To: Mike Hommey <mh@glandium.org>

Cc: 474281@bugs.debian.org, Jon Dowland <jon+bts@alcopop.org>

Subject: Re: Bug#474281: Acknowledgement (iceweasel: ftbfs on armel: temporary object destruction order)

Date: Wed, 9 Apr 2008 01:35:06 +0300

This bug also affect xulrunner build on unstable with gcc-4.3 now
as default:

http://buildd.debian.org/fetch.cgi?pkg=xulrunner;ver=1.8.1.13-1;arch=armel;stamp=1207348728

-snip-
configure:10281: checking for iconv in -lc
configure:10303: c++ -o conftest  -fshort-wchar -pthread   -Wl,--as-needed conftest.C -lc  -ldl -lm  1>&5
/usr/bin/ld: ERROR: /tmp/ccAhgliI.o: Conflicting definitions of wchar_t
/usr/bin/ld: failed to merge target specific data of file /tmp/ccAhgliI.o
-snip-

On Sat, Apr 05, 2008 at 10:25:45AM +0200, Mike Hommey wrote:
> On Sat, Apr 05, 2008 at 12:13:45AM +0300, Riku Voipio wrote:
> > $ cat test.c
> > #include <stddef.h>
> > #include <wchar.h>
> > 
> > int main() {
> > ; return 0; }
> > all6500-2:~/icew
> > $ c++ -c -fno-strict-aliasing -fshort-wchar test.c
> > $ echo $?
> > 0
> > $ c++  -fno-strict-aliasing -fshort-wchar test.c
> > /usr/bin/ld: ERROR: /tmp/ccKVwN1s.o: Conflicting definitions of wchar_t
> > /usr/bin/ld: failed to merge target specific data of file
> > /tmp/ccKVwN1s.o
> > collect2: ld returned 1 exit status
> > 
> > A quick test confirms, test.c compiles fine with g++-4.2, but fails with
> > g++-4.3.

> Seems like a candidate for a gcc regression :-/

Not really, gcc has just become more strict.

on arm EABI, wchar_t is "unsigned int", while -fshort-wchar enforces
"short unsigned int". One is creating code that is incompatible with
platform ABI, which the linker refuses to mix.

Message #59 received at 474281@bugs.debian.org (full text, mbox, reply):

From: Mike Hommey <mh@glandium.org>

To: Riku Voipio <riku.voipio@iki.fi>

Cc: 474281@bugs.debian.org, Jon Dowland <jon+bts@alcopop.org>

Subject: Re: Bug#474281: Acknowledgement (iceweasel: ftbfs on armel: temporary object destruction order)

Date: Wed, 9 Apr 2008 08:29:17 +0200

On Wed, Apr 09, 2008 at 01:35:06AM +0300, Riku Voipio wrote:
> Not really, gcc has just become more strict.
> 
> on arm EABI, wchar_t is "unsigned int", while -fshort-wchar enforces
> "short unsigned int". One is creating code that is incompatible with
> platform ABI, which the linker refuses to mix.

Is arm EABI the only ABI with such incompatibility ?

Mike

PS: I wonder if gcc shouldn't dump -fshort-wchar in such situation. The
option doesn't make sense if it will always lead to this error.

Message #64 received at 474281@bugs.debian.org (full text, mbox, reply):

From: Riku Voipio <riku.voipio@iki.fi>

To: Mike Hommey <mh@glandium.org>

Cc: 474281@bugs.debian.org, Jon Dowland <jon+bts@alcopop.org>

Subject: Re: Bug#474281: Acknowledgement (iceweasel: ftbfs on armel: temporary object destruction order)

Date: Wed, 9 Apr 2008 12:06:51 +0300

On Wed, Apr 09, 2008 at 08:29:17AM +0200, Mike Hommey wrote:
> On Wed, Apr 09, 2008 at 01:35:06AM +0300, Riku Voipio wrote:
> > on arm EABI, wchar_t is "unsigned int", while -fshort-wchar enforces
> > "short unsigned int". One is creating code that is incompatible with
> > platform ABI, which the linker refuses to mix.

> Is arm EABI the only ABI with such incompatibility ?

Good question. All other our archs seem to define wchar_t as int,
while on arm it's unsigned int. Handling signed values
on arm is slower than unsigned and negative values for wchar_t make
little point.

The gcc manpage seems to indicate that -fshort-wchar creates
ABI incompatability, and is only usefull for wine programming
(since windowsen wchar_t is unsigned short). Why in practice it's
only causing problems on arm eabi with gcc >= 4.3 is weird.

> PS: I wonder if gcc shouldn't dump -fshort-wchar in such situation. The
> option doesn't make sense if it will always lead to this error.

Theoretically it is valid option on arm eabi too, if you are not
linking against the system libraries (building kernel, bootloader or
static binaries with your own libc-like functionality ).

-- 
"rm -rf" only sounds scary if you don't have backups

Message #69 received at 474281@bugs.debian.org (full text, mbox, reply):

From: Riku Voipio <riku.voipio@iki.fi>

To: Mike Hommey <mh@glandium.org>

Cc: 474281@bugs.debian.org, Jon Dowland <jon+bts@alcopop.org>, control@bugs.debian.org

Subject: Re: Bug#474281: Acknowledgement (iceweasel: ftbfs on armel: temporary object destruction order)

Date: Tue, 15 Apr 2008 13:00:40 +0300

tags 474281 + patch
thanks

Well, if the error happens at linking stage, changing AC_TRY_COMPILE to
AC_TRY_LINK will catch it, and configure will not bother using
-short-wchar anymore.

This needs to be applied to all packages of mozilla origin and
auto(re)confed.

-- 
"rm -rf" only sounds scary if you don't have backups

Message #74 received at 474281@bugs.debian.org (full text, mbox, reply):

From: Riku Voipio <riku.voipio@iki.fi>

To: Mike Hommey <mh@glandium.org>

Cc: 474281@bugs.debian.org, Jon Dowland <jon+bts@alcopop.org>

Subject: Re: Bug#474281: Acknowledgement (iceweasel: ftbfs on armel: temporary object destruction order)

Date: Tue, 15 Apr 2008 13:01:47 +0300

[Message part 1 (text/plain, inline)]

On Tue, Apr 15, 2008 at 01:00:40PM +0300, Riku Voipio wrote:
> This needs to be applied to all packages of mozilla origin and
> auto(re)confed.

Actually add the patch..

-- 
"rm -rf" only sounds scary if you don't have backups

[mozilla.patch (text/plain, attachment)]

Message #87 received at 476302-done@bugs.debian.org (full text, mbox, reply):

From: "Michael Casadevall" <sonicmctails@gmail.com>

To: 476302-done@bugs.debian.org

Subject: Fixed with last upload

Date: Mon, 20 Oct 2008 09:18:58 -0400

This was fixed with the upload of 2.0.0.17.
Michael

Send a report that this bug log contains spam.