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.
Created attachment 570122 [details] [diff] [review] proposed fix
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.
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 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.
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.
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.
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.
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
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.
(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.
Is it installed on the "OS X 10.6.2 Try build" servers?
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)
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.
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.
https://tbpl.mozilla.org/?tree=Try&rev=dccd5eebd8a9 for the supplemental nsprpub fix.
https://tbpl.mozilla.org/?tree=Try&rev=b3b96c611bbc for both patches together.
Can you file a separate bug for the NSPR change? It makes it a bit easier to track them.
Comment on attachment 574421 [details] [diff] [review] Supplemental fix for the breakage NSPR fix moved to bug 702997.
https://tbpl.mozilla.org/?tree=Try&rev=228aa7447719 (trying again on top of today's m-c now that bug 702997 has landed.
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.
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.