Upcoming changes to the Linux 32-bits and Android builders

[Mike Hommey]

Hi,

With the increasing number of reports of local builds for Linux and
Android hitting the 32-bits address space limits when linking, and with
the fact that gcc 4.7 on try does hit that limit on PGO builds, it has
become necessary to switch the 32-bits Linux and Android builds to
64-bits environments and toolchains.

This switch is going to happen some time today (May 15).

In practice, this doesn't change much of anything, since the 64-bits
toolchain just happily builds 32-bits binaries. However, since the
Android NDK currently in use (r8c) doesn't have a 64-bits toolchain,
we'll also switch to NDK r8e.

We also arranged things such that pushing to try should work as long as
the patch for bug 864262 is applied, which is the case on most branches
tips, including aurora, beta, release and esr17. For Android, the
previous 32-bits toolchain will be used if pushing branches without bug
859984 applied, which isn't a problem, as we made the 32-bits NDK
available in the 64-bits environments.

Following this, we're going to switch all Linux builds to gcc 4.7, later
this week.

Cheers,

Mike

[Chris Peterson]

On 5/15/13 2:42 AM, Mike Hommey wrote:
> Following this, we're going to switch all Linux builds to gcc 4.7, later
> this week.

Android NDK r8e also includes gcc 4.7. We may want to investigate
updating to gcc 4.7 on Android, too.


chris

[Trevor Saunders]

We use stripped down ndks in tooltool that only contain one toolchain
because of size concerns, however upgrading to gcc 4.7 on android
shouldn't be hard. You can generate an appropriate ndk with the script
in bug 859984 then get that uploaded by releng and you should be good to
try gcc 4.7 on try and when you're ready change the mozconfigs in the
tree. Doing that's on my list of things to do, but I don't mind if
someone else does it first.

Trev

>
>
> chris
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

[Mike Hommey]

On Wed, May 15, 2013 at 11:42:33AM +0200, Mike Hommey wrote:
> Hi,
>
> With the increasing number of reports of local builds for Linux and
> Android hitting the 32-bits address space limits when linking, and with
> the fact that gcc 4.7 on try does hit that limit on PGO builds, it has
> become necessary to switch the 32-bits Linux and Android builds to
> 64-bits environments and toolchains.
>
> This switch is going to happen some time today (May 15).

So, interestingly, while buildbot reconfig was triggered yesterday,
somehow it didn't make the builds actually switch to 32-bits
environment. After Justin Wood did a re-reconfig this morning (european
time), things got straight up... but non-clobber builds got red because
of the python virtualenv still containing a 32-bits binary when the
system python library is now 64-bits.

While I think I triggered all the necessary clobbers on all branches
where it's needed, but I didn't inspect all of them to retrigger failed
builds. In the event there are some project branches with the following
error:

error while loading shared libraries: libpython2.7.so.1.0: wrong ELF
class: ELFCLASS64

Please retrigger these builds after checking the clobberer says the last
clobber is newer than 2013-05-16 01:10:00 PDT.

> Following this, we're going to switch all Linux builds to gcc 4.7, later
> this week.

Chances are this is not going to happen this week. Something in the last
569 changesets before 15ba59a74221 broke some webgl mochitest when built
with gcc 4.7. Filed bug 872960.

Mike

[Mike Hommey]

On Thu, May 16, 2013 at 10:50:18AM +0200, Mike Hommey wrote:
> > Following this, we're going to switch all Linux builds to gcc 4.7, later
> > this week.
>
> Chances are this is not going to happen this week. Something in the last
> 569 changesets before 15ba59a74221 broke some webgl mochitest when built
> with gcc 4.7. Filed bug 872960.

This turned out to be caused by bug 817700, which was backed out because
the same was happening on PGO builds with gcc 4.5. So everything is in
order to switch Linux builds to gcc 4.7, which I just landed on inbound.

Mike