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

Status: RESOLVED FIXED

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

Description

[[e-mail] (:bhearsum)]

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)

Comment 1

[John Hopkins (:jhopkins)]

Attachment: [rpm-sources] build gcc with --disable-gnu-unique-object

Comment 2

[John Hopkins (:jhopkins)]

I'll build the RPMs and put them somewhere for testing.

Comment 3

[Justin Wood (:Callek)]

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

Comment 4

[John Hopkins (:jhopkins)]

Attachment: [rpm-sources] centos6 spec files

Copied the centos5/ files into centos6/ and modified to build under mock.

Built RPMs are in http://people.mozilla.org/~jhopkins/bug827354/

Comment 5

[John Hopkins (:jhopkins)]

Attachment: RPM build instructions

Comment 6

[[e-mail] (:bhearsum)]

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?

Comment 7

[Mike Hommey [:glandium]]

(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)

Comment 8

[John Hopkins (:jhopkins)]

Running builds and tests in staging.  Will upload the builds to my people account when they're done.

Comment 9

[John Hopkins (:jhopkins)]

Have run into some issues with our staging setup.  This is still being worked on.

Comment 10

[[e-mail] (:bhearsum)]

(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?

Comment 11

[John Hopkins (:jhopkins)]

I've uploaded new GCC RPMs here:

 http://people.mozilla.org/~jhopkins/bug827354/gcc45_0moz4-4.5.2-0moz4.i686.rpm
 http://people.mozilla.org/~jhopkins/bug827354/gcc45_0moz4-4.5.2-0moz4.x86_64.rpm

Staging builds are running now.

Comment 12

[John Hopkins (:jhopkins)]

A mozilla-central 32-bit build is available for testing here:

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

Comment 13

[Mike Hommey [:glandium]]

(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.

Comment 14

[John Hopkins (:jhopkins)]

mozilla-central-linux64 build:

 http://people.mozilla.org/~jhopkins/bug827354/builds/mozilla-central-linux64/1359560969/

Comment 15

[John Hopkins (:jhopkins)]

mozilla-central-linux64-pgo build:

 http://people.mozilla.org/~jhopkins/bug827354/builds/mozilla-central-linux64-pgo/1359564493/

Comment 16

[John Hopkins (:jhopkins)]

mozilla-central-linux-pgo build:

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

Comment 17

[John Hopkins (:jhopkins)]

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.

Comment 18

[John Hopkins (:jhopkins)]

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.

Comment 19

[Mike Hommey [:glandium]]

Debian Lenny doesn't have the version of GTK+ we require.

Comment 20

[John Hopkins (:jhopkins)]

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/

Comment 21

[John Hopkins (:jhopkins)]

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.

Comment 22

[John Hopkins (:jhopkins)]

Attachment: [rpm-sources] rebuild on centos6

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.

Comment 23

[John Hopkins (:jhopkins)]

Comment on attachment 710277 [details] [diff] [review]
[rpm-sources] rebuild on centos6

Landed in http://hg.mozilla.org/build/rpm-sources/rev/223964127252

Comment 24

[Nick Thomas [:nthomas] (UTC+12)]

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).

Comment 25

[John Hopkins (:jhopkins)]

gcc45_0moz4 RPMs copied into releng Yum repo.  No build configs are using it yet.

Comment 26

[u279076]

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.

Comment 27

[u279076]

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

Comment 28

[Mike Hommey [:glandium]]

(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?

Comment 29

[u279076]

(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.

Comment 30

[[e-mail] (:bhearsum)]

(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?

Comment 31

[John Hopkins (:jhopkins)]

For posterity, the command used by glandium to check the build was:
$ readelf -D -s *.so | grep UNIQUE

Comment 32

[Armen [:armenzg]]

Do you need talos-r3-fed-001 anymore? It's locked on slavealloc.