Closed Bug 827354 Opened 7 years ago Closed 7 years ago

rebuild mock gcc with --disable-gnu-unique-object

Categories

(Release Engineering :: Release Automation: Other, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: bhearsum, Assigned: jhopkins)

References

Details

Attachments

(1 file, 3 obsolete files)

We may need a better gcc for 17.0.2esr builds. I think we also need it for 18, but I'm not sure if I understand that part correctly.

On Mon, Jan 07, 2013 at 04:27:35PM +0100, Mike Hommey wrote:
> Hi,
> 
> The switch to mock on ESR Linux builds made the following symbols
> exported with the GNU_UNIQUE flag:
> 
>   std::basic_string<char, std::char_traits<char>, pool_allocator<char> >::_Rep::_S_terminal
>   std::basic_string<char, std::char_traits<char>, pool_allocator<char> >::_Rep::_S_empty_rep_storage
>   std::basic_string<unsigned short, base::string16_char_traits, std::allocator<unsigned short> >::_Rep::_S_max_size
>   std::basic_string<unsigned short, base::string16_char_traits, std::allocator<unsigned short> >::_Rep::_S_terminal
>   std::basic_string<unsigned short, base::string16_char_traits, std::allocator<unsigned short> >::_Rep::_S_empty_rep_storage
>   std::basic_string<unsigned short, base::string16_char_traits, std::allocator<unsigned short> >::npos
> 
> This makes the 17.0.2esr builds fail to run on systems with glibc < 2.11
> while 17.0.1esr worked
> (see https://bugzilla.mozilla.org/show_bug.cgi?id=723487#c58 and
> https://bugzilla.mozilla.org/show_bug.cgi?id=826567#c6)
> 
> It's a feature combination of gcc and ld. While we haven't changed the
> gcc version in mock, the new ld version in mock supports the gcc
> feature.
> The gcc feature can't unfortunately be disabled without rebuilding gcc,
> and the ld support for it can't be disabled with a flag ; only gold
> supports disabling it with a flag (and only fairly recent versions).
> 
> The easiest might be for us to deploy a gcc rebuilt with the
> --disable-gnu-unique-object flag, provided version 4.5.x had that
> configure flag.

I was assuming the gcc rpm we are using in the mock environment was the
same, but it's not, and that's what made the change: the
gnu-unique-object feature enables itself when gcc is built and both gas
and glibc support it, which is the case in mock. So it's not the ld
bump, but the rebuild of gcc that did it. We could rebuild gcc with
--disable-gnu-unique-object (I checked gcc 4.5.2 configure has that
flag)
I'll build the RPMs and put them somewhere for testing.
Assignee: nobody → jhopkins
Comment on attachment 698724 [details] [diff] [review]
[rpm-sources] build gcc with --disable-gnu-unique-object

>diff --git a/gcc45/centos5-i686/gcc45.spec b/gcc45/centos5-i686/gcc45.spec
>--- a/gcc45/centos5-i686/gcc45.spec
>+++ b/gcc45/centos5-i686/gcc45.spec

Nit: Don't modify cent5, unless you plan to deploy a cent5 rpm as well. Either way we need a cent6 spec
Attached patch [rpm-sources] centos6 spec files (obsolete) — Splinter Review
Copied the centos5/ files into centos6/ and modified to build under mock.

Built RPMs are in http://people.mozilla.org/~jhopkins/bug827354/
Attachment #698724 - Attachment is obsolete: true
Attachment #701284 - Flags: review?(catlee)
Attached file RPM build instructions (obsolete) —
So, we've got a rebuilt gcc. What do we need to do to verify that it works, and doesn't regress anything else? Do we just need a Firefox build done with it?
Flags: needinfo?(mh+mozilla)
(In reply to Ben Hearsum [:bhearsum] from comment #6)
> So, we've got a rebuilt gcc. What do we need to do to verify that it works,
> and doesn't regress anything else? Do we just need a Firefox build done with
> it?

Build + tests, I'd say, with and without PGO for good measure. (although i'd say it's overzealous checking)
Flags: needinfo?(mh+mozilla)
Attachment #701284 - Flags: review?(catlee) → review+
Running builds and tests in staging.  Will upload the builds to my people account when they're done.
Depends on: 833024
No longer depends on: 833024
Blocks: 832601
Have run into some issues with our staging setup.  This is still being worked on.
(In reply to John Hopkins (:jhopkins) from comment #9)
> Have run into some issues with our staging setup.  This is still being
> worked on.

What are the issues?
A mozilla-central 32-bit build is available for testing here:

 http://people.mozilla.org/~jhopkins/bug827354/builds/mozilla-central/1359411518/
(In reply to John Hopkins (:jhopkins) from comment #12)
> A mozilla-central 32-bit build is available for testing here:
> 
>  http://people.mozilla.org/~jhopkins/bug827354/builds/mozilla-central/
> 1359411518/

From the perspective of gnu unique symbols, this build is, as expected, not using them.
And finally,

mozilla-central-linux (rebuilt using final rpm build):

 http://people.mozilla.org/~jhopkins/bug827354/builds/mozilla-central-linux/1359574165/

I'm planning to run a basic install/startup test of each build on Debian Lenny and CentOS 6.

I've also filed bug 836433 which is related to the deployment of the new gcc RPM.
I've tested that the builds above work on CentOS 6.2 32-bit and 64-bit but still failed on a stock Debian Lenny system (32-bit):

 symbol lookup error: libxul.so: undefined symbol: gtk_widget_set_can_focus

The original error in bug 832601 was:

 XPCOMGlueLoad error for file /home/test/lib/firefox/libxpcom.so:
libxul.so: cannot open shared object file: No such file or directory
Couldn't load XPCOM.

Could this be a new dependency introduced by mozilla-central?  Perhaps a rebuild of mozilla-release with the new compiler would be more appropriate.
Flags: needinfo?(mh+mozilla)
Debian Lenny doesn't have the version of GTK+ we require.
Flags: needinfo?(mh+mozilla)
Rebuilding the mozilla-release branch with the rebuilt compiler results in the same GTK error on Debian Lenny as in comment 18.

 http://people.mozilla.org/~jhopkins/bug827354/builds/mozilla-release-linux/1359663791/
The rebuilt gcc works and solves the glibc compatibility problem as expected.  Camaleon tested a mozilla-release build on his Debian 5 system to confirm in https://bugzilla.mozilla.org/show_bug.cgi?id=832601#c8 and it passed.

Next step is writing patches for deployment of this new gcc package and fixing related bug 836433.
Built on centos6.2 'minimal' OS install plus:

gcc, glibc-devel, make, perl, mercurial, rpm-build for 32/64bit builds
and glibc-devel.i686 only on 64bit build.

Build command was simply: rpmbuild -ba gcc45.spec

Provides and Requires have been modified from the original gcc45.spec so as not to advertise package-internal libraries to the RPM database.
Attachment #701284 - Attachment is obsolete: true
Attachment #701296 - Attachment is obsolete: true
Attachment #710277 - Flags: review?(catlee)
Attachment #710277 - Flags: review?(catlee) → review+
Comment on attachment 710277 [details] [diff] [review]
[rpm-sources] rebuild on centos6

Landed in http://hg.mozilla.org/build/rpm-sources/rev/223964127252
Attachment #710277 - Flags: checked-in+
Deployment note from the channel meeting today: 
RelMan would like to switch to using the new gcc after 17.0.3 ships on Feb 19th, so that QA can test for any other requirements regressions and we can flag the change to the enterprise mailing list. We would need to be able to revert the change if a chemspill came along prior to the next scheduled release on April 2nd.

No decision was made regarding using the new gcc for Firefox 20 or later (ie non-esr).
gcc45_0moz4 RPMs copied into releng Yum repo.  No build configs are using it yet.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
I've done some basic dogfooding of Nightly builds since landing these changes and have found no regressions. 

Testing included:
* Running Mozmill functional automation
* Running Mozmill update automation
* Running manual update tests with partial and complete updates
* Testing installation and startup (stub and normal installer)
* Testing crash reporter and session restore
* Testing various Web Developer tools
* Testing private browsing
* Testing add-ons and the add-ons manager
* Testing video playback (html and flash)
* Testing PDF.js and Social API

Platforms Tested:
* Windows 7 64-bit
* Windows 8 32-bit
* Mac OSX 10.8
* Ubuntu 12.04 32-bit

I will be advising our community to keep an eye out for any issues and escalate them as appropriate. Please let me know if there are any high risk areas you think we've missed.
I forgot to mention that I also tested with the following add-ons:
* Adblock Plus 2.2.2
* Crash Me Now! Advanced 0.4
* Download Statusbar 0.9.10
* DownloadHelper 4.9.13
* DownThemAll! 2.0.15
* Easy YouTube Video Downloader 6.7
* Firebug 1.11.1
* FlashGot 1.5.4.1
* Greasemonkey 1.7.1
* ImTranslator 5.1.1
* InvisibleHand 3.8.28
* NoScript 2.6.4.4
* WOT 20130129
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #26)
> I've done some basic dogfooding of Nightly builds since landing these
> changes and have found no regressions. 

Did you really mean this bug or bug 755724?
(In reply to Mike Hommey [:glandium] from comment #28)
> (In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #26)
> > I've done some basic dogfooding of Nightly builds since landing these
> > changes and have found no regressions. 
> 
> Did you really mean this bug or bug 755724?

Sorry, I don't know why I thought it was this bug. I'll cross-post to the right bug.
(In reply to John Hopkins (:jhopkins) from comment #25)
> gcc45_0moz4 RPMs copied into releng Yum repo.  No build configs are using it
> yet.

Just to be clear -- are we planning to enable this as part of bugs 813613, 825630, and 825959?
For posterity, the command used by glandium to check the build was:
$ readelf -D -s *.so | grep UNIQUE
Do you need talos-r3-fed-001 anymore? It's locked on slavealloc.
Blocks: 855882
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.