GN: Use x86_64-nacl-gcc with -m32 rather then i686-nacl-gcc

GN: Use x86_64-nacl-gcc with -m32 rather then i686-nacl-gcc

i686-nacl-gcc is not in goma (its a simple shell script
wrapper arond x86_64-nacl-gcc and this is not supported
currently in goma)

Committed: https://crrev.com/93bf7095de46409cb10665ebe27ec9521a465946
Cr-Commit-Position: refs/heads/master@{#375810}

[Sam Clegg, 2016-02-12 18:17:02]

sbc@chromium.org changed reviewers:
+ dpranke@chromium.org, mcgrathr@chromium.org

[Sam Clegg, 2016-02-12 18:17:02]

This means that the 32-bit linux gn bots are currently falling back to the local
compiler for nacl-glibc targets.

Somehow I thought we have configured the bots to never fall back to always use
goma?   In which case the x86 linux gn builders should be failing.  Is that not
true anymore, or do we need to fix something to make it true again?

[Sam Clegg, 2016-02-12 18:21:23]

The CQ bit was checked by sbc@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-02-12 18:22:40]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1693913002/60001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1693913002/60001

[commit-bot: I haz the power, 2016-02-12 19:55:47]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-02-12 19:55:48]

Dry run: This issue passed the CQ dry run.

[Dirk Pranke, 2016-02-12 20:37:23]

I defer this to Roland; the change looks plausible but I don't know if it's the
right thing to do or not.

[Dirk Pranke, 2016-02-17 03:27:48]

On 2016/02/12 20:37:23, Dirk Pranke wrote:
> I defer this to Roland; the change looks plausible but I don't know if it's
the
> right thing to do or not.

Could this explain a failure on the win bots I'm seeing in one of my CLs?  

https://build.chromium.org/p/tryserver.chromium.win/builders/win8_chromium_gn...
https://build.chromium.org/p/tryserver.chromium.win/builders/win8_chromium_gn...

If so, lgtm :).

[Sam Clegg, 2016-02-17 05:50:03]

On 2016/02/17 03:27:48, Dirk Pranke wrote:
> On 2016/02/12 20:37:23, Dirk Pranke wrote:
> > I defer this to Roland; the change looks plausible but I don't know if it's
> the
> > right thing to do or not.
> 
> Could this explain a failure on the win bots I'm seeing in one of my CLs?  
> 
>
https://build.chromium.org/p/tryserver.chromium.win/builders/win8_chromium_gn...
>
https://build.chromium.org/p/tryserver.chromium.win/builders/win8_chromium_gn...
> 

Yes, this looks like the same problem.   I would have though it would be
consistently happening in all gn/goma/x86_32/nacl builders.

> If so, lgtm :).

[Sam Clegg, 2016-02-17 05:50:11]

The CQ bit was checked by sbc@chromium.org

[commit-bot: I haz the power, 2016-02-17 05:51:06]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1693913002/60001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1693913002/60001

[commit-bot: I haz the power, 2016-02-17 06:23:36]

Committed patchset #4 (id:60001)

[commit-bot: I haz the power, 2016-02-17 06:24:59]

Description was changed from

==========
GN: Use x86_64-nacl-gcc with -m32 rather then i686-nacl-gcc

i686-nacl-gcc is not in goma (its a simple shell script
wrapper arond x86_64-nacl-gcc and this is not supported
currently in goma)
==========

to

==========
GN: Use x86_64-nacl-gcc with -m32 rather then i686-nacl-gcc

i686-nacl-gcc is not in goma (its a simple shell script
wrapper arond x86_64-nacl-gcc and this is not supported
currently in goma)

Committed: https://crrev.com/93bf7095de46409cb10665ebe27ec9521a465946
Cr-Commit-Position: refs/heads/master@{#375810}
==========

[commit-bot: I haz the power, 2016-02-17 06:25:00]

Patchset 4 (id:??) landed as
https://crrev.com/93bf7095de46409cb10665ebe27ec9521a465946
Cr-Commit-Position: refs/heads/master@{#375810}

[Roland McGrath, 2016-02-17 21:31:09]

Firstly, s/then/than/ in the title.  Someone needs to teach this Englishman
English!

Secondly, the other clang/gcc toolchains put -m32/-m64 in a config rather than
in the toolchain.  //build/config/compiler:compiler_cpu_abi does it already and
that already applies to the NaCl toolchains.  So now the -m32 being passed is
redundant.

Furthermore, we should be treating the nacl-clang toolchains and the nacl-gcc
toolchains the same in such regards.  So whatever changes are made to gcc
toolchains should have analogous changes to clang toolchains.

[Sam Clegg, 2016-02-17 22:12:07]

On 2016/02/17 21:31:09, Roland McGrath wrote:
> Firstly, s/then/than/ in the title.  Someone needs to teach this Englishman
> English!
>
 
Indeed!

> Secondly, the other clang/gcc toolchains put -m32/-m64 in a config rather than
> in the toolchain.  //build/config/compiler:compiler_cpu_abi does it already
and
> that already applies to the NaCl toolchains.  So now the -m32 being passed is
> redundant.

OK. I'll take a look.

> Furthermore, we should be treating the nacl-clang toolchains and the nacl-gcc
> toolchains the same in such regards.  So whatever changes are made to gcc
> toolchains should have analogous changes to clang toolchains.

Why not use the i686- prefix when the binary is available (nacl-clang) and fall
back to using -m32 when it isn't (nacl-gcc)?

[Roland McGrath, 2016-02-17 23:07:32]

On 2016/02/17 22:12:07, Sam Clegg wrote:
> Why not use the i686- prefix when the binary is available (nacl-clang) and
fall
> back to using -m32 when it isn't (nacl-gcc)?

The i686-nacl-foo commands are always available.  Them ever not being usable is
some quirk of GOMA.  The most maintainable thing is to be consistent across all
the toolchains.  If the reason to be one way or another (i686-nacl-foo vs
x86_64-nacl-foo -m32) is GOMA's limitations, then that merits some comments
about the choice made.  But regardless of that, consistency is better than
inconsistency.

[Sam Clegg, 2016-02-17 23:22:30]

On 2016/02/17 23:07:32, Roland McGrath wrote:
> On 2016/02/17 22:12:07, Sam Clegg wrote:
> > Why not use the i686- prefix when the binary is available (nacl-clang) and
> fall
> > back to using -m32 when it isn't (nacl-gcc)?
> 
> The i686-nacl-foo commands are always available.  Them ever not being usable
is
> some quirk of GOMA.  The most maintainable thing is to be consistent across
all
> the toolchains.  If the reason to be one way or another (i686-nacl-foo vs
> x86_64-nacl-foo -m32) is GOMA's limitations, then that merits some comments
> about the choice made.  But regardless of that, consistency is better than
> inconsistency.

OK I'll make it consistent with comments.