Last Comment Bug 697881 - XCode 4.2 no longer provides a gcc-4.2
: XCode 4.2 no longer provides a gcc-4.2
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Build Config (show other bugs)
: Trunk
: x86_64 Mac OS X
: -- normal (vote)
: mozilla11
Assigned To: Ralph Giles (:rillian) needinfo me
:
: Gregory Szorc [:gps]
Mentors:
Depends on: 702997
Blocks: 697821 700175
  Show dependency treegraph
 
Reported: 2011-10-27 16:19 PDT by Ralph Giles (:rillian) needinfo me
Modified: 2012-02-01 14:00 PST (History)
11 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
proposed fix (3.38 KB, patch)
2011-10-27 17:02 PDT, Ralph Giles (:rillian) needinfo me
no flags Details | Diff | Splinter Review
proposed fix (3.49 KB, patch)
2011-10-31 15:36 PDT, Ralph Giles (:rillian) needinfo me
ted: review-
Details | Diff | Splinter Review
proposed fix (3.32 KB, patch)
2011-11-01 09:31 PDT, Ralph Giles (:rillian) needinfo me
ted: review+
Details | Diff | Splinter Review
Supplemental fix for the breakage (14.10 KB, patch)
2011-11-14 10:20 PST, Hubert Figuiere [:hub]
no flags Details | Diff | Splinter Review
Supplemental fix for the breakage (14.02 KB, patch)
2011-11-14 14:19 PST, Ralph Giles (:rillian) needinfo me
hub: review+
giles: checkin-
Details | Diff | Splinter Review

Description Ralph Giles (:rillian) needinfo me 2011-10-27 16:19:47 PDT
Trying a fresh build with the recently released XCode 4.2 on MacOS X 10.7.2, configure immediately fails because the compiler (gcc-4.2) fails to create executables. This turns out to be because the system doesn't include a gcc-4.2.

Bug 513353 says configure sets CC (and CXX) to 'gcc-4.2' because it's faster than 'gcc-4.0' which is what Apple shipped as 'gcc' at the time. 'gcc' is now:

i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)

So configure should be changed to use gcc-4.2 only if it is present.
Comment 1 Ralph Giles (:rillian) needinfo me 2011-10-27 17:02:53 PDT
Created attachment 570122 [details] [diff] [review]
proposed fix
Comment 2 Ralph Giles (:rillian) needinfo me 2011-10-27 17:22:25 PDT
Hmm, the configure output with MOZ_PATH_PROGS is a little confusing:

checking for gcc-4.2... (cached) /usr/bin/gcc
checking for g++-4.2... (cached) /usr/bin/g++

But this was by far the lightest weight way I could think of to do this.
Comment 3 Ralph Giles (:rillian) needinfo me 2011-10-31 15:36:52 PDT
Created attachment 570869 [details] [diff] [review]
proposed fix

nieder pointed out the previous patch ignored CC and CXX from the enviroment, so it was no longer possible to override the gcc-4.2 default. This version restores that behaviour.
Comment 4 Ted Mielczarek [:ted.mielczarek] 2011-11-01 04:02:03 PDT
Comment on attachment 570869 [details] [diff] [review]
proposed fix

Review of attachment 570869 [details] [diff] [review]:
-----------------------------------------------------------------

::: configure.in
@@ +203,5 @@
>      if test -z "$MIDL"; then MIDL=midl; fi
>      ;;
>  *-darwin*)
> +    # gcc-4.2 was faster than gcc on older darwin, so
> +    # use that specific version if it's available.

It's not that it was faster, but "gcc" was gcc 4.0 at one point.

::: js/src/configure.in
@@ -196,5 @@
>      if test -z "$MIDL"; then MIDL=midl; fi
>      ;;
> -*-darwin*)
> -    if test -z "$CC"; then CC=gcc-4.2; fi
> -    if test -z "$CXX"; then CXX=g++-4.2; fi

This will break standalone JS builds on 10.6 and earlier. You need to do the same sort of thing you did in the top-level configure.
Comment 5 Ralph Giles (:rillian) needinfo me 2011-11-01 09:31:17 PDT
Created attachment 571034 [details] [diff] [review]
proposed fix

Thanks for the review. Updated patch.

> It's not that it was faster, but "gcc" was gcc 4.0 at one point.

This was based on comment 1 of bug 513353, "Using gcc 4.2 on OS X provides performance gains over using gcc 4.0 (the system default)." What was the reason for preferring 4.2 then? 4.0 couldn't compile spidermonkey?

> This will break standalone JS builds on 10.6 and earlier. You need to do the same sort of thing you did in the top-level configure.

Ok, I made the two cases parallel.
Comment 6 Ralph Giles (:rillian) needinfo me 2011-11-07 08:25:57 PST
Thanks, Ted.
Comment 7 Ed Morley [:emorley] 2011-11-07 17:09:52 PST
I pushed a few checkin-neededs to try (top three changesets here excl the trychooser https://tbpl.mozilla.org/?tree=Try&rev=faeb3613b876), of which this was one. However builds on OS X 10.6 failed, and I believe this to be the most likely cause.
Comment 8 Ralph Giles (:rillian) needinfo me 2011-11-08 09:14:20 PST
I don't understand the log; it looks like nsinstall is returning an error code without printing a message. The builds are using gcc-4.2 which is the intended behaviour on 10.6.

In any case, we've missed the land window for nightly 10. I'll try to debug so we can land on 11, but I think we should also backport this to aurora 10 once we're clear it works.
Comment 9 Ralph Giles (:rillian) needinfo me 2011-11-09 16:36:46 PST
I haven't been able to reproduce this on 10.5 or 10.7, but it does seem to be real:

https://tbpl.mozilla.org/?tree=Try&rev=dad93d45592e
Comment 10 Ralph Giles (:rillian) needinfo me 2011-11-10 22:52:06 PST
So Hub and I today tracked the problem down to nspr/configure.

Compiling with build/macos/universal/mozconfig, it looks like target_cpu is set to x86_64 at http://mxr.mozilla.org/mozilla-central/source/nsprpub/configure.in#1350. There's no match in the case statement, so the default -arch ppc is set, even though that's completely inappropriate. Then nsinstall, compiled for ppc, fails to run without the rosetta emulation environment, which iirc isn't supported by Apple on Mac OS 10.6.

Which raises the question of how the try server build succeeds even without this patch! And our 10.6 test build does in fact fail with this afternoon's mozilla-central tip and the try server's reported mozconfig. Adding a x86_64 match to the case section in nsprpub/configure.in and regenerating nsprpub/configure allows the build to succeed.

So, I think we almost know what's going on. I'll try to figure out the why and if we can fix it next week.
Comment 11 Nomis101 2011-11-11 09:11:44 PST
(In reply to Ralph Giles (:rillian) from comment #10)
> the rosetta emulation environment, which iirc
> isn't supported by Apple on Mac OS 10.6.
Rosetta is supported on 10.6, but not installed by default (but it will be reinstalled if there is a need or it is still installed if you upgrade from 10.5). Support is dropped since 10.7.
Comment 12 Ralph Giles (:rillian) needinfo me 2011-11-11 11:07:39 PST
Is it installed on the "OS X 10.6.2 Try build" servers?
Comment 13 Hubert Figuiere [:hub] 2011-11-14 10:20:34 PST
Created attachment 574333 [details] [diff] [review]
Supplemental fix for the breakage

This patch does not require attachment 571034 [details] [diff] [review] (above) and a fix a build problem on Snow Leopard that occur without it (see comment 7)
Comment 14 Hubert Figuiere [:hub] 2011-11-14 10:24:48 PST
I just wanted to mention this is what we worked out with Ralph Giles on Friday to have the build work here since I have a system that seems to match the requirements.
Comment 15 Ralph Giles (:rillian) needinfo me 2011-11-14 14:19:26 PST
Created attachment 574421 [details] [diff] [review]
Supplemental fix for the breakage

Thanks, Hub. I've added a commit message and removed the accidental reversion of the MKS line-ending hack in the generated configure file. Please review.

Also asking Ted to ok the change the nsprpub module.
Comment 16 Ralph Giles (:rillian) needinfo me 2011-11-14 14:20:35 PST
https://tbpl.mozilla.org/?tree=Try&rev=dccd5eebd8a9 for the supplemental nsprpub fix.
Comment 17 Ralph Giles (:rillian) needinfo me 2011-11-14 15:10:50 PST
https://tbpl.mozilla.org/?tree=Try&rev=b3b96c611bbc for both patches together.
Comment 18 Ted Mielczarek [:ted.mielczarek] 2011-11-16 07:35:44 PST
Can you file a separate bug for the NSPR change? It makes it a bit easier to track them.
Comment 19 Ralph Giles (:rillian) needinfo me 2011-11-16 10:10:06 PST
Comment on attachment 574421 [details] [diff] [review]
Supplemental fix for the breakage

NSPR fix moved to bug 702997.
Comment 20 Ralph Giles (:rillian) needinfo me 2011-12-15 17:08:02 PST
https://tbpl.mozilla.org/?tree=Try&rev=228aa7447719

(trying again on top of today's m-c now that bug 702997 has landed.
Comment 21 Ralph Giles (:rillian) needinfo me 2011-12-15 17:17:39 PST
https://tbpl.mozilla.org/?tree=Try&rev=bb91724dcc04

Sorry, forgot debug builds. I believe it was the OS X64 opt build which failed last time, but the tbpl links are dead, so I can't verify. Best to be safe, anyway.
Comment 22 Ralph Giles (:rillian) needinfo me 2011-12-16 15:31:54 PST
Try builds look ok. The Mac builds are clean. Linux64 JP failure happens on adjacent try builds as well, and the orange is known intermittent or spurious.
Comment 24 Marco Bonardo [::mak] 2011-12-19 05:30:37 PST
https://hg.mozilla.org/mozilla-central/rev/8288419ba591

Note You need to log in before you can comment on or make changes to this bug.