From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1147 invoked by alias); 25 Nov 2009 09:18:04 -0000 Received: (qmail 1122 invoked by uid 22791); 25 Nov 2009 09:18:03 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 25 Nov 2009 09:17:56 +0000 Received: from int-mx03.intmail.prod.int.phx2.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.16]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id nAP9HtAq002128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Nov 2009 04:17:55 -0500 Received: from zebedee.pink (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx03.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id nAP9HpPj014235; Wed, 25 Nov 2009 04:17:53 -0500 Message-ID: <4B0CF63E.7060503@redhat.com> Date: Wed, 25 Nov 2009 09:18:00 -0000 From: Andrew Haley User-Agent: Thunderbird 2.0.0.23 (X11/20090825) MIME-Version: 1.0 To: Ehren Metcalfe CC: gcc@gcc.gnu.org, dev-static-analysis@lists.mozilla.org Subject: Re: Problems compiling Mozilla with GCC 4.5 References: <934be2480911242316x6841144cw6484412e9b9e079d@mail.gmail.com> In-Reply-To: <934be2480911242316x6841144cw6484412e9b9e079d@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-11/txt/msg00659.txt.bz2 Ehren Metcalfe wrote: > I've recently come across a couple of issues trying to compile Firefox > trunk with 4.5 (I have a very simple plugin that I need to run on > mozilla-central). I've posted two bugs here > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42139 and here > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42171 > > I''m not particularly concerned about the first, which can be bypassed > by disabling optimization on the problem file, but the second, a link > error, is a show stopper. Can anyone think of a way to sidestep the > problem? I'm not even sure I've addressed the bug to the right place, > but it would seem that if the same version of ld chokes during a 4.5 > compile, but does fine with an earlier version of gcc, then it's > really not a binutils issue. I'm a bit out of my element here though > so any suggestions would be welcome. Is the symbol `nsAccessibleWrap::ReturnString(nsAString_internal&)::returnedString' defined anywhere? Andrew.