The default bug view has changed. See this FAQ.

Tamarin does not build on Snow Leopard

RESOLVED FIXED in Q3 11 - Serrano

Status

Tamarin
Build Config
P1
normal
RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: Bernd Mathiske, Assigned: James Sudduth)

Tracking

unspecified
Q3 11 - Serrano
x86
Mac OS X
Bug Flags:
flashplayer-qrb +
flashplayer-triage +

Details

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

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

The configure.py script writes the old Tiger SDK into the Makefile, but Snow Leopard has a new SDK. C++ compilation then fails to find numerous header files.

Reproducible: Always

Steps to Reproduce:
1.Follow directions on developer page
2.When invoking "make" in "objdir-release", the build fails
Actual Results:  
Files in Mac OS X SDK 10.4 are not found

Expected Results:  
Files found

The configuration script should have picked up the newer version of the SDK (10.5)

The bug's cause was identified and a manual Makefile hack as a temporary workaround was provided to me by Mason Chang.
(Reporter)

Comment 1

7 years ago
It seems the configure script actually is aware that there is an SDK version 10.5. However, it chooses the SDK based on the cpu and it determines that the cpu is "i686". Now, what does that mean? Do we really distinguish Pentium Pro from regular i386? And how would we know? The value of the cpu variable stems from `uname -m`, which reports "i386". I do not have access to pre-snow leopard machines. Did it report "x86_64" on those, maybe? That would everything a lot.

Comment 2

7 years ago
I presume that the configure script is attempting to use an older SDK where
possible in order to maximize compatibility with older OS deployments in the
field.  The default installation of Xcode 3.2.1 (current as of this writing)
includes only the 10.5 and 10.6 SDKs, but the 10.4u SDK can be selected in
a custom install.  Doing so allows the header files in the SDK to be found,
but the build still fails:

Compiling MMgc/FixedAlloc
In file included from /Users/wmaddox/tamarin-redux/platform/mac/mac-platform.h:92,
                 from /Users/wmaddox/tamarin-redux/VMPI/VMPI.h:83,
                 from /Users/wmaddox/tamarin-redux/MMgc/MMgc.h:44,
                 from /Users/wmaddox/tamarin-redux/MMgc/FixedAlloc.cpp:39:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/stdarg.h:4:25: error: stdarg.h: No such file or directory

Notice that the stdarg.h file in the SDK has been found.  The contents of
this file simply delegates to the remainder of the search path using an
#include_next directive.  The other SDK versions do this as well, presumably
because stdarg.h is closely coupled to the GCC release and provided with the
compiler rather than the C/C++ library.

Comment 3

7 years ago
Editing the Makefile to use CC=gcc-4.0 and CXX=g++-4.0 allows the build
to complete.  Did the default GCC version change in Snow Leopard? On my
system, gcc-4.2 and g++-4.2 are the defaults.

Comment 4

7 years ago
The following snippets were extracted from the --verbose output of the
compilation of MMgc/FixedAlloc with g++ 4.0 and 4.2.  It is obvious that
the 4.2 compiler is searching for a version-specific directory that is
not present in the 10.4u SDK.

With respect to my earlier comment, I have confirmed that GCC 4.2 was
first supported in Snow Leopard.

=== G++ 4.0 ===

ignoring nonexistent directory "/Developer/SDKs/MacOSX10.4u.sdk/usr/local/include"
ignoring nonexistent directory "/Developer/SDKs/MacOSX10.4u.sdk/usr/lib/gcc/i686-apple-darwin10/4.0.1/../../../../i686-apple-da\
rwin10/include"
#include "..." search starts here:
#include <...> search starts here:
 /Users/wmaddox/tamarin-redux
 /Users/wmaddox/tamarin-redux/MMgc
 /Users/wmaddox/tamarin-redux/core
 /Users/wmaddox/tamarin-redux/pcre
 /Users/wmaddox/tamarin-redux/eval
 /Users/wmaddox/tamarin-redux/platform
 /Users/wmaddox/tamarin-redux/other-licenses/zlib
 /Users/wmaddox/tamarin-redux/shell
 /Users/wmaddox/tamarin-redux/VMPI
 /Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0
 /Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/i686-apple-darwin10
 /Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/backward
 /Developer/SDKs/MacOSX10.4u.sdk/usr/lib/gcc/i686-apple-darwin10/4.0.1/include
 /Developer/SDKs/MacOSX10.4u.sdk/usr/include
 /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks (framework directory)
 /Developer/SDKs/MacOSX10.4u.sdk/Library/Frameworks (framework directory)

=== G++ 4.2 ===

ignoring nonexistent directory "/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.2.1"
ignoring nonexistent directory "/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.2.1/i686-apple-darwin10/x86_64"
ignoring nonexistent directory "/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.2.1/backward"
ignoring nonexistent directory "/Developer/SDKs/MacOSX10.4u.sdk/usr/local/include"
ignoring nonexistent directory "/Developer/SDKs/MacOSX10.4u.sdk/usr/lib/gcc/i686-apple-darwin10/4.2.1/include"
ignoring nonexistent directory "/Developer/SDKs/MacOSX10.4u.sdk/usr/lib/gcc/i686-apple-darwin10/4.2.1/../../../../i686-apple-da\
rwin10/include"
#include "..." search starts here:
#include <...> search starts here:
 /Users/wmaddox/tamarin-redux
 /Users/wmaddox/tamarin-redux/MMgc
 /Users/wmaddox/tamarin-redux/core
 /Users/wmaddox/tamarin-redux/pcre
 /Users/wmaddox/tamarin-redux/eval
 /Users/wmaddox/tamarin-redux/platform
 /Users/wmaddox/tamarin-redux/other-licenses/zlib
 /Users/wmaddox/tamarin-redux/shell
 /Users/wmaddox/tamarin-redux/VMPI
 /Developer/SDKs/MacOSX10.4u.sdk/usr/include
 /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks (framework directory)
 /Developer/SDKs/MacOSX10.4u.sdk/Library/Frameworks (framework directory)

Comment 5

7 years ago
(In reply to comment #3)
> Editing the Makefile to use CC=gcc-4.0 and CXX=g++-4.0 allows the build
> to complete.  Did the default GCC version change in Snow Leopard? On my
> system, gcc-4.2 and g++-4.2 are the defaults.

on my 10.5.8 machine gcc-4.0 is the default

Comment 6

7 years ago
gcc-4.2 is the default in SL + XC3.2.

Comment 7

7 years ago
There used to be an option to --enable-leopard which would then use 10.5 sdk, this was change to use the 10.5 sdk if the cpu type is x86_64 or ppc64 only. The cpu type needs to be passed into the script in order for it to be properly set for these architectures (uname will return ppc or i686)

../configure.py --enable-shell --target=x86_64-darwin
../configure.py --enable-shell --target=ppc64-darwin

--target=[cputype]-[ostype]

Comment 8

7 years ago
We should probably decouple the SDK and CPU options -- not all combinations are valid. (eg, 10.4: x86,ppc,maybe-x64?, 10.5=x86,ppc,x64, 10.6=x86,x64)

Updated

7 years ago
Assignee: nobody → dschaffe
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Target Milestone: --- → flash10.2

Comment 9

7 years ago
Does anyone have a specific proposal to fix this?

Comment 10

7 years ago
with no args, configure should pass no extra args to gcc and should get whatever it decides is the default.  for compiling for Macos 10.4 on a 10.5/6 system, configure.py should take an option for that, either a variant on --target, or a dedicated option.

Updated

7 years ago
Duplicate of this bug: 543234

Comment 12

7 years ago
proposal:

* configure.py with no args gives you no SDK options, and gcc/g++
* need a new "--target" option for OS 10.4
* enabling that option should set the SDK to 10.4 and also set CC/CPP to gcc-4.0 and g++-4.0

Comment 13

7 years ago
if someone breaks Alloc to return NULL when kCanFail isn't set it would be nice to still crash although I suppose it isn't necessary

Comment 14

7 years ago
doh ignore comment 13, wrong bug

Updated

7 years ago
Assignee: dschaffe → jsudduth
Flags: flashplayer-triage+
Flags: flashplayer-qrb+
Priority: -- → P1
(Assignee)

Comment 15

7 years ago
Created attachment 449186 [details] [diff] [review]
Changes to allow Tamarin to build on Snow Leopard

The changes enable the three points of the fix proposal. Taken in order:

* configure.py with no args gives you no SDK options, and gcc/g++
Implemented to use the latest SDK installed in /Developer/SDKs, MacOSX10.4u.sdk, MacOSX10.5.sdk, or MacOSX10.6.sdk and the installed gcc/g++.

* need a new "--target" option for OS 10.4
Added a new option called "--use-104u-sdk"; this is a standalone option, not a --target option. Please suggest a better name if you don't like this one.

* enabling that option should set the SDK to 10.4 and also set CC/CPP to
gcc-4.0 and g++-4.0
When "--use-104u-sdk" is passed in you will get the MacOSX10.4u.sdk and gcc-4.0/g++-4.0.

I didn't see a need to change the code for any platform except the Mac, but please double-check that I haven't missed some side effect on another platform arising from these changes.
Attachment #449186 - Flags: superreview?(edwsmith)
Attachment #449186 - Flags: review?(brbaker)

Comment 16

7 years ago
On snow leopard, with patch applied, i ran

$ cd objdir
$ ../configure.py --enable-shell --enable-debug --enable-debugger

the patch intends: "configure.py with no args gives you no SDK options"

yet in the Makefile, I see:

  APP_CXXFLAGS= ... -mmacosx-version-min=10.6 -isysroot /Developer/SDKs/MacOSX10.6.sdk -arch i686

Since I did not specify a target or SDK on the commandline, I would not expect the makefile to specify one either; I would have expected the makefile to just use GCC defaults.  The makefile does work, however now configure.py must be kept in sync with gcc which is contrary to my proposal in comment #12.

bug or intentional?

Updated

7 years ago
Attachment #449186 - Flags: superreview?(edwsmith) → superreview-
(Assignee)

Comment 17

7 years ago
The change was intentional based on my misunderstanding the fix proposal. I'll fix the patch.

Comment 18

7 years ago
the hope is that the script will continue to work unmodified on macos 10.7, when that comes; as written i think it would stick 10.6 into the makefile explicitly and then require a change again in the future.  is that a correct assumption?
(Assignee)

Comment 19

7 years ago
Yes, that's correct.
(Assignee)

Comment 20

7 years ago
A problem came to light with building for the MacOSX10.4u.sdk on a Snow Leopard machine. As noted above gcc is configured to expect certain folders to be present in the installed SDKs. For example, my 10.6 machine expects /Developer/SDKs/MacOSX10.6.sdk/usr/lib/gcc/i686-apple-darwin10. But the MacOSX10.4u.sdk  on the build machines has /Developer/SDKs/MacOSX10.6.sdk/usr/lib/gcc/i686-apple-darwin8 (note the "8" at the end). Some also have a "*darwin9" folder. In this case gcc will fire the error about not being able to find stdarg.h noted in W. Maddox's comment from 01-04-2010. If I copy my /Developer/SDKs/MacOSX10.6.sdk/usr/lib/gcc/i686-apple-darwin10 folder to the MacOSX10.4u.sdk folder Tamarin will build.

When we set up Snow Leopard build machines we'll have to remember to add (or get in a distribution, probaby from Apple) the "*darwin10" folders. Bill Maddox says he got his Xcode environment from Apple and the 10.4u SDK distribution in that package included /arm-apple-darwin10, /darwin, /i686-apple-darwin10, and /powerpc-apple-darwin10.
(Assignee)

Comment 21

7 years ago
Created attachment 452174 [details] [diff] [review]
Build Tamarin on Snow Leopard

This patch corrects the "configure.py with no args gives you no SDK options, and gcc/g++" part of the proposal to work exactly that way with no defaults provided by configure.py; you get what gcc/g++ the machine defaults to and no sdk when you pass no sdk option.

In addition, because it was suggested in the bug that we decouple the cpu and sdk options, the "--use-104u-sdk" switch in the last patch has been changed to "--mac-sdk". This is a more general switch that allows you to specify a 10.4u, 10.5 or 10.6 sdk.

When you specify "--mac-sdk=104u" you'll get the 10.4u sdk and gcc/g++ will be set to version 4.0. When you pass "--mac-sdk=105" or "--mac-sdk=106" you will get the gcc/g++ that the machine defaults to. We could add another switch to inndependently control gcc/g++ choice if desired.

These changes mean that tamarin-redux.py, argo.py and sandbox.py had to be updated with the new switch to continue to build as they do now. Also, the documentation at:

https://developer.mozilla.org/En/Tamarin/Tamarin_Build_Documentation#Running_Tamarin_compliance_tests

will have to be changed, namely the section on Cross-platform build, to reflect these points:

- you must specify which sdk you want to use
- if you don't pass "--mac-sdk" you won't build with an sdk and you'll get the default gcc/g++
- if you pass "--mac-sdk=104u" you will get the 10.4u sdk and gcc/g++ 4.0
- the --target option will no longer select an sdk, it only sets the target
Attachment #449186 - Attachment is obsolete: true
Attachment #452174 - Flags: review?(edwsmith)
Attachment #452174 - Flags: feedback?(brbaker)
Attachment #449186 - Flags: review?(brbaker)
(Assignee)

Comment 22

7 years ago
Created attachment 452328 [details] [diff] [review]
Fix typo in previous patch.

Noticed a typo in tamarin-redux.py, argo.py and sandbox.py (a stray comma before the new --mac-sdk switch).
Attachment #452174 - Attachment is obsolete: true
Attachment #452328 - Flags: review?(edwsmith)
Attachment #452328 - Flags: feedback?(brbaker)
Attachment #452174 - Flags: review?(edwsmith)
Attachment #452174 - Flags: feedback?(brbaker)

Comment 23

7 years ago
Comment on attachment 452328 [details] [diff] [review]
Fix typo in previous patch.

nothing obviously wrong.  I did not review the buildbot script changes, only configure.py.  If there's an area you want closer review, let me know, otherwise if it works out of the box with no args on snow leopard x86, i'm satisfied.
Attachment #452328 - Flags: review?(edwsmith) → review+
(Assignee)

Updated

7 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED

Updated

7 years ago
Attachment #452328 - Flags: feedback?(brbaker) → feedback+
You need to log in before you can comment on or make changes to this bug.