1142908 - Spidermonkey arm simulator automated builds are using a GCC 4.4 host compiler

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Mike Hommey [:glandium]]

Either HOST_CC/HOST_CXX should be set, or the build should not pretend to be a cross-compile (adding a --host with the same value as --target would fix that)

Comment 1

[Steve Fink [:sfink] [:s:]]

(In reply to Mike Hommey [:glandium] from comment #0)
> Either HOST_CC/HOST_CXX should be set, or the build should not pretend to be
> a cross-compile (adding a --host with the same value as --target would fix
> that)

Hm. I don't actually understand exactly what is going on here, but these have to target a 32-bit build, so I don't think just setting --host to --target is correct given that they're running on 64-bit linux.

I added specific logic that prevents setting CC/CXX in this case. I don't remember why. Perhaps it's just a matter of setting HOST_* instead? I'll give that a try, unless you tell me what's more likely to work.

I certainly did not intend for those builds to use the ancient piece of crap default compiler, but I guess that's what they're getting.

Comment 2

[Steve Fink [:sfink] [:s:]]

Oh, wait. The above comment is incorrect.

The logic I referred to that avoids setting CC/CXX is only activated when the actual host it's running on is an arm architecture (uname -m == arm). Which is irrelevant here, and CC/CXX *are* getting set to gcc-4.7.2. And from what I can tell, the vast majority of the build *is* using 4.7.2, not 4.4.6.

This part seems to be using 4.4.6:

make -C tests/makefiles/autodeps check
...
***************************************************************************
check_mkdir.tpy: python version is 2.7.7 (default, Jun 19 2014, 08:59:14) 
[GCC 4.4.6 20110731 (Red Hat 4.4.6-3)]
***************************************************************************

So one question is why that isn't using the CC/CXX environment variables. Another is why you think this build is using 4.4.6 and more specifically, why it's a problem if it's only for some internal 'autodeps' checking thing.

Comment 3

[Steve Fink [:sfink] [:s:]]

ni? for: why the autodeps stuff is ignoring CC/CXX, and whether it matters.

Comment 4

[Mike Hommey [:glandium]]

That gcc string is part of the python version banner, and is a red herring.

$ python
Python 2.7.9 (default, Mar  1 2015, 12:57:24) 
[GCC 4.9.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> print sys.version
2.7.9 (default, Mar  1 2015, 12:57:24) 
[GCC 4.9.2]
>>> 

(In reply to Steve Fink [:sfink, :s:] from comment #1)
> (In reply to Mike Hommey [:glandium] from comment #0)
> > Either HOST_CC/HOST_CXX should be set, or the build should not pretend to be
> > a cross-compile (adding a --host with the same value as --target would fix
> > that)
> 
> Hm. I don't actually understand exactly what is going on here, but these
> have to target a 32-bit build, so I don't think just setting --host to
> --target is correct given that they're running on 64-bit linux.

And our 64-bit linux hosts can run 32-bit binaries just fine. Setting --target and --host to the same value is what we do on firefox builds:
https://dxr.mozilla.org/mozilla-central/source/build/unix/mozconfig.linux32

Comment 5

[David Baron :dbaron: 🏴󠁵󠁳󠁣󠁡󠁿 ⌚UTC-8]

To be clear, what this blocks is that I was trying to add logic to configure.in that checks our minimum compiler version for the host compiler (when cross compiling) in addition to its existing checks for the target compiler so that we don't have to worry about extra language support issues in binaries that are built for the host as part of the build process.  This was the only build that turned red when I tried to enforce a minimum of gcc 4.6 for the host compiler when cross-compiling.

Comment 6

[Mike Hommey [:glandium]]

Attachment: Avoid arm simulator builds being considered cross-compiled

https://treeherder.mozilla.org/#/jobs?repo=try&revision=2136a114ae12

Still building after 20 minutes, so it will likely go green.

Comment 7

[Mike Hommey [:glandium]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/43cbfc770c1e

Comment 8

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/43cbfc770c1e

Comment 9

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-release/rev/517741a918b0

Comment 10

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/517741a918b0