firefox version 4.0+nobinonly-0ubuntu1 failed to build on i386

Bug #765970 reported by Matthias Klose on 2011-04-19
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Fix Released
Medium
firefox (Ubuntu)
High
Chris Coulson
Oneiric
High
Chris Coulson

Bug Description

firefox version 4.0+nobinonly-0ubuntu1 failed to build on i386
Link to failed build: https://launchpad.net/ubuntu/+archive/test-rebuild-20110413/+buildjob/2449963

Direct link to the build log: https://launchpad.net/ubuntu/+archive/test-rebuild-20110413/+buildjob/2449963/+files/buildlog_ubuntu-natty-i386.firefox_4.0%2Bnobinonly-0ubuntu1_FAILEDTOBUILD.txt.gz

This log snippet might be of interest, since it triggered the matcher 'Purging chroot-autobuild'.
Excerpt 12387 lines into the build log:

/build/buildd/firefox-4.0+nobinonly/build-tree/mozilla/xpcom/glue/nsEnumeratorUtils.cpp:50:7: note: 'const class EmptyEnumeratorImpl' has no user-provided default constructor
make[6]: *** [nsEnumeratorUtils.o] Error 1
make[6]: Leaving directory `/build/buildd/firefox-4.0+nobinonly/build-tree/mozilla/objdir-i686-linux-gnu/xpcom/glue'
make[5]: *** [libs] Error 2
make[5]: Leaving directory `/build/buildd/firefox-4.0+nobinonly/build-tree/mozilla/objdir-i686-linux-gnu/xpcom'
make[4]: *** [libs_tier_platform] Error 2
make[4]: Leaving directory `/build/buildd/firefox-4.0+nobinonly/build-tree/mozilla/objdir-i686-linux-gnu'
make[3]: *** [tier_platform] Error 2
make[3]: Leaving directory `/build/buildd/firefox-4.0+nobinonly/build-tree/mozilla/objdir-i686-linux-gnu'
make[2]: *** [default] Error 2
make[2]: Leaving directory `/build/buildd/firefox-4.0+nobinonly/build-tree/mozilla/objdir-i686-linux-gnu'
make[1]: *** [build] Error 2
make[1]: Leaving directory `/build/buildd/firefox-4.0+nobinonly/build-tree/mozilla'
make: *** [debian/stamp-makefile-build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
******************************************************************************
Build finished at 20110414-1644
FAILED [dpkg-buildpackage died]
Purging chroot-autobuild/build/buildd/firefox-4.0+nobinonly

Created attachment 501245
patch

nsSimpleUnicharStreamFactory is missing a user defined constructor,
but in nsUnicharInputStream.cpp a const variable of this type is defined.

This is not valid c++. For more information see "Default initialization of
const variable of a class type requires user-defined default constructor" in
http://clang.llvm.org/compatibility.html#c++

The reporter's summary and initial comment were both lame. I'm merely adjusting
the summary and providing a better link. I am not passing judgement on the
quality of the bug report.

http://clang.llvm.org/compatibility.html#default_init_const

Just as with the other bug, the missing constructor is intentional so that GCC does not emit a initialization function. Absent a detailed explanation from a language lawyer, I don't think I want to accept this change.

Given the discussion on bug 623123, are you ok with it?

*** Bug 614789 has been marked as a duplicate of this bug. ***

Matthias Klose (doko) on 2011-04-19
Changed in firefox (Ubuntu):
importance: Undecided → High

*** Bug 645469 has been marked as a duplicate of this bug. ***

(In reply to comment #2)
> Just as with the other bug, the missing constructor is intentional so that GCC
> does not emit a initialization function. Absent a detailed explanation from a
> language lawyer, I don't think I want to accept this change.

A bit late, but language lawyer here, see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44499#c2 for chapter and verse. As pointed out by some of the dups of this bug, GCC 4.6 rejects this too, see the note I added to http://gcc.gnu.org/gcc-4.6/changes.html#cplusplus

I see that the commit adds empty user-defined constructors. Did anyone consider the alternative of adding an initializer instead, as I suggested in the GCC 4.6 changes and in Bug 645469 c5?
That might avoid emitting an initialization function.

(In reply to comment #8)
> I see that the commit adds empty user-defined constructors. Did anyone consider
> the alternative of adding an initializer instead, as I suggested in the GCC 4.6
> changes and in Bug 645469 c5?
> That might avoid emitting an initialization function.

I don't think it makes any difference in the generated code.

Changed in firefox (Ubuntu):
assignee: nobody → Chris Coulson (chrisccoulson)
status: New → In Progress
Changed in firefox:
importance: Unknown → Medium
status: Unknown → Fix Released
Chris Coulson (chrisccoulson) wrote :

Firefox 5 (which I'm going to upload to Oneiric) has the fixes for this already

Changed in firefox (Ubuntu Oneiric):
status: In Progress → Fix Committed
Launchpad Janitor (janitor) wrote :
Download full text (4.8 KiB)

This bug was fixed in the package firefox - 5.0~b2+build1+nobinonly-0ubuntu1

---------------
firefox (5.0~b2+build1+nobinonly-0ubuntu1) oneiric; urgency=low

  * New upstream release from the beta channel (FIREFOX_5_0b2_BUILD1)
    - Fixes LP: #765970

  * Switch to mozilla-beta
    - update debian/mozclient/firefox.conf
  * Drop support for building with an external xulrunner
    - update debian/apport/firefox.in
    - update debian/firefox.install.in
    - update debian/firefox.lintian-overrides.in
    - update debian/firefox.sh.in
    - update debian/mozconfig.in
    - update debian/rules
  * Ditch all the version-number based branding selection. Do this all
    purely on the channel name now
    - remove debian/firefox-beta.desktop.in
    - remove debian/firefox-nightly.desktop.in
    - remove debian/firefox-unofficial.desktop.in
    - rename debian/firefox-final.desktop.in => debian/firefox.desktop.in
    - update debian/firefox.desktop.in
    - update debian/rules
    - update debian/firefox.sh.in
  * Drop the DEB_ENABLE_IPC option, now that IPC is mandatory
    - update debian/rules
    - update debian/apport/firefox.in
    - update debian/firefox.install.in
    - update debian/mozconfig.in
  * Build language packs directly from the firefox source
    + Fixes LP: #294187 - Firefox Locales should install locale specific
      search plugins
    + Rip out the bits to create a en-US.xpi
      - update debian/rules
      - remove debian/translation-support/install.rdf.in
    + Include compare-locales FIREFOX_5_0b1_BUILD1 from
      http://hg.mozilla.org/build/compare-locales. It's needed for merging
      en-US strings with incomplete locales
    + Pull l10n data in to tarball from bzr
      - update debian/mozclient/firefox.conf
    + Configure build for creating language packs by configuring with
      "--with-l10n-base="
      - update debian/mozconfig.in
    + Store the list of locales to ship, and provide a way of automatically
      generating that list and the control file entries from the upstream
      source. Also provide a way to blacklist languages. We map languages
      to package names using langpack-o-matic (and also get descriptions
      from there too)
      - update debian/rules
      - add debian/locales-supported
      - add debian/control.langpacks
      - update debian/control
      - add debian/locale-blacklist
      - add debian/refresh-supported-locales.pl
    + Add common-build-indep hook to build the translation xpi's
      - update debian/rules
    + Add common-binary-post-install-indep to install the xpi's and
      searchplugins in to the correct debian packages
      - update debian/rules
      - add debian/get-xpi-id.py
    + When rebuilding debian/control in the clean target, fail the build
      if the control file was out-of-date. This ensures that we don't
      accidentally drop language packs, and forces me to maintain an
      up-to-date control file in bzr
      - update debian/rules
    + Apply vendor patches to localized searchplugins too
      - update debian/patches/ubuntu-codes-amazon.patch
      - add debian/patches/ubuntu-codes-baidu.patch
      - update debian/patches/ubuntu-codes-google.p...

Read more...

Changed in firefox (Ubuntu Oneiric):
status: Fix Committed → Fix Released

requesting approval for mozilla-2.0 branch: with Fedora 15, gcc 4.6.0, FF4 will not compile. #developers pointed me to this bug.

the 2.0 branch doesn't have any planned updates, what is the purpose of the nomination?

I wonder why this is marked as resolved fix? In Fedora 15 it is still a problem, was the patch applied upstream and then not brought into Fedora? I'm trying to rebuild sunbird, and this bug in xulrunner is breaking the sunbird build. I just created an updated version of the xulrunner rpm using this patch to fix the problem, but if there is something upstream I can grab it is probably better to use that.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.