build failure: stdarg.h missing on 10.6

VERIFIED DUPLICATE of bug 537817

Status

P3
normal
VERIFIED DUPLICATE of bug 537817
9 years ago
6 years ago

People

(Reporter: alexmac, Assigned: cpeyer)

Tracking

unspecified
flash10.2.x-Spicy
x86_64
Mac OS X
Bug Flags:
flashplayer-qrb +

Details

Attachments

(1 attachment)

(Reporter)

Description

9 years ago
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
(Reporter)

Comment 1

9 years ago
Created attachment 424427 [details] [diff] [review]
Fix build breakage on OSX 10.6
Attachment #424427 - Flags: review?(stejohns)

Comment 2

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

Updated

9 years ago
Attachment #424427 - Flags: review?(cpeyer)
(Assignee)

Comment 3

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

Looks good.
Attachment #424427 - Flags: review?(cpeyer) → review+

Updated

9 years ago
Assignee: nobody → cpeyer
Severity: major → normal
Component: Virtual Machine → Build Config
Flags: flashplayer-qrb+
Priority: -- → P3
QA Contact: vm → build-config
Target Milestone: --- → flash10.1

Updated

9 years ago
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

Comment 4

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

Comment 5

9 years ago
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

9 years ago
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

9 years ago
(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

9 years ago
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

9 years ago
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?

Updated

9 years ago
Attachment #424427 - Flags: review?(stejohns) → review?(rwinchel)

Updated

9 years ago
Target Milestone: flash10.1 → flash10.1.1

Comment 10

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

Updated

9 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 537817
(Assignee)

Updated

8 years ago
Status: RESOLVED → VERIFIED

Updated

8 years ago
Attachment #424427 - Flags: review?(rwinchel)

Updated

8 years ago
Target Milestone: flash10.1.1 → flash10.2.x-Spicy
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.
You need to log in before you can comment on or make changes to this bug.