697881 - XCode 4.2 no longer provides a gcc-4.2

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Ralph Giles (:rillian)]

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)]

Attachment: proposed fix

Comment 2

[Ralph Giles (:rillian)]

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)]

Attachment: 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

[(not currently active) Ted Mielczarek]

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)]

Attachment: 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)]

Thanks, Ted.

Comment 7

[Ed Morley [:emorley]]

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)]

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)]

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)]

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]

(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)]

Is it installed on the "OS X 10.6.2 Try build" servers?

Comment 13

[Hubert Figuiere [:hub]]

Attachment: 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]]

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)]

Attachment: 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)]

https://tbpl.mozilla.org/?tree=Try&rev=dccd5eebd8a9 for the supplemental nsprpub fix.

Comment 17

[Ralph Giles (:rillian)]

https://tbpl.mozilla.org/?tree=Try&rev=b3b96c611bbc for both patches together.

Comment 18

[(not currently active) Ted Mielczarek]

Can you file a separate bug for the NSPR change? It makes it a bit easier to track them.

Comment 19

[Ralph Giles (:rillian)]

Comment on attachment 574421 [details] [diff] [review]
Supplemental fix for the breakage

NSPR fix moved to bug 702997.

Comment 20

[Ralph Giles (:rillian)]

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)]

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)]

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 23

[Dão Gottwald [:dao]]

http://hg.mozilla.org/integration/mozilla-inbound/rev/8288419ba591

Comment 24

[Marco Bonardo [:mak]]

https://hg.mozilla.org/mozilla-central/rev/8288419ba591