543234 - build failure: stdarg.h missing on 10.6

Status: VERIFIED DUPLICATE of bug 537817

(Tamarin Graveyard :: Build Config, defect, P3)

Description

[Alex Macdonald]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_2; en-us) AppleWebKit/531.21.8 (KHTML, like Gecko) Version/4.0.4 Safari/531.21.10
Build Identifier: HEAD

On my OSX 10.6.2 machine with XCode 3.2.1 the configuration.py script incorrectly identifies my machine as 32bit and tries to compile against the OSX10.4u SDK. Although this SDK does exist the build system is unable to find stdarg.h and so compilation fails.

The machine is misidentified because of what uname reports:
Darwin alexmac.local 10.2.0 Darwin Kernel Version 10.2.0: Tue Nov  3 10:37:10 PST 2009; root:xnu-1486.2.11~1/RELEASE_I386 i386

The proposed fix adds a test which checks if the major kernel version of darwin is greater or equal to 10, if it is then it must be a 64bit machine.

Reproducible: Always

Comment 1

[Alex Macdonald]

Attachment: Fix build breakage on OSX 10.6

Comment 2

[Steven Johnson]

A change of this sort will need to be run past our build guys first, to be sure it doesn't break testing assumptions.

Comment 3

[Chris Peyer]

Comment on attachment 424427 [details] [diff] [review]
Fix build breakage on OSX 10.6

Looks good.

Comment 4

[Tommy Reilly]

This patch makes 10.6 machines build x86_64 by default, surely that isn't what we want.

Comment 5

[Tommy Reilly]

I think what's needed is a way to force folks compiling with 10.6 to use the 10.5 (or 10.6) SDK.

Comment 6

[Lars T Hansen]

Since we continue to support 10.4 we probably need to be able to compile against the 10.4 SDK.  And when building with Xcode, building against 10.4 works no problem (provided it's installed, which it is not by default on 10.6).

Comment 7

[Steven Johnson]

(In reply to comment #5)
> I think what's needed is a way to force folks compiling with 10.6 to use the
> 10.5 (or 10.6) SDK.

No way -- I would support optionally building with 10.5, but 10.4 support (for x86-32) is still a requirement for Flash, so we should continue to vet against it.

Comment 8

[Tommy Reilly]

Optionally is good.   Right now you can't build a 32 bit shell with the build scripts at all on 10.6 which is annoying.   Using 10.5/10.6 SDK is one such option.  The xcode project builds against 10.4 just fine on 10.6 so I don't know what's broken with with our build scripts.   Personally I'd like to see an configure.py switch or a env var that let you specify what SDK you wanted.

Comment 9

[Tommy Reilly]

http://bugs.python.org/issue6957 say's that we need to use gcc-4.0/g++-4.0 to build for 10.4 on 10.6.  This fixed it for me.   I'm not sure how to make the configure scripts detect 10.6 and make this change can someone more build/python savvy make this fix?

Comment 10

[Lars T Hansen]

FWIW, editing the Makefile to use gcc-4.0 and g++-4.0 makes it produce a working shell.

Comment 12

[Felix S. Klock II [:pnkfelix, :fklock]]

I just ran into this again (after almost two years!), this time when trying to build on a 10.7 machine with an admittedly old version of Xcode 3 installed.

I think the re-injection of the problem may be due to changes associated with Bug 772793 ; see in particular

  http://hg.mozilla.org/tamarin-redux/diff/36aa7dd8026a/configure.py

but I am not 100% certain of that it is related to that changeset.

The main thing I have noted is that it if I hack the Makefile to change the reference to MacOSX10.7.sdk into MacOS10.6.sdk instead, then the build appears to go through.

(It also appears that a Debug-Debugger avmshell build does not even include the -isysroot directive that is the source of the hypothetically problematic reference to MacOSX10.7.sdk; I only encountered it when attempting a Release-Debugger avmshell build.  YMMV.)

It may well be that I am simply failing to invoke configure.py with the correct arguments.  But even so, we may want to consider putting some sort of preprocessor guard or a comment aroun the area of that include of <stdarg.h>, with a pointer to the relevant bugzilla tickets (Bug 543234, Bug 537817, maybe others) and advice on what the correct next steps are, because it is pretty frustrating when one first encounters the issue.