Last Comment Bug 537817 - Tamarin does not build on Snow Leopard
: Tamarin does not build on Snow Leopard
Status: RESOLVED FIXED
:
Product: Tamarin
Classification: Components
Component: Build Config (show other bugs)
: unspecified
: x86 Mac OS X
: P1 normal (vote)
: Q3 11 - Serrano
Assigned To: James Sudduth
:
:
Mentors:
: 543234 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-01-04 14:47 PST by Bernd Mathiske
Modified: 2010-07-13 06:06 PDT (History)
10 users (show)
trbaker: flashplayer‑qrb+
trbaker: flashplayer‑triage+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Changes to allow Tamarin to build on Snow Leopard (7.65 KB, patch)
2010-06-03 20:50 PDT, James Sudduth
edwsmith: superreview-
Details | Diff | Splinter Review
Build Tamarin on Snow Leopard (47.65 KB, patch)
2010-06-17 21:07 PDT, James Sudduth
no flags Details | Diff | Splinter Review
Fix typo in previous patch. (47.56 KB, patch)
2010-06-18 13:35 PDT, James Sudduth
edwsmith: review+
brbaker: feedback+
Details | Diff | Splinter Review

Description Bernd Mathiske 2010-01-04 14:47:54 PST
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.
Comment 1 Bernd Mathiske 2010-01-04 16:00:27 PST
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 William Maddox 2010-01-04 16:40:15 PST
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 William Maddox 2010-01-04 16:46:20 PST
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 William Maddox 2010-01-04 18:41:44 PST
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 Edwin Smith 2010-01-05 06:02:13 PST
(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 Steven Johnson 2010-01-05 09:52:11 PST
gcc-4.2 is the default in SL + XC3.2.
Comment 7 Brent Baker 2010-01-05 09:59:41 PST
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 Steven Johnson 2010-01-05 10:03:15 PST
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)
Comment 9 Edwin Smith 2010-03-08 09:56:31 PST
Does anyone have a specific proposal to fix this?
Comment 10 Edwin Smith 2010-03-10 04:32:39 PST
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.
Comment 11 Edwin Smith 2010-03-15 16:45:09 PDT
*** Bug 543234 has been marked as a duplicate of this bug. ***
Comment 12 Edwin Smith 2010-03-15 16:46:22 PDT
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 Tommy Reilly 2010-04-08 08:49:10 PDT
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 Tommy Reilly 2010-04-08 09:12:22 PDT
doh ignore comment 13, wrong bug
Comment 15 James Sudduth 2010-06-03 20:50:24 PDT
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.
Comment 16 Edwin Smith 2010-06-08 07:19:23 PDT
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?
Comment 17 James Sudduth 2010-06-08 09:51:22 PDT
The change was intentional based on my misunderstanding the fix proposal. I'll fix the patch.
Comment 18 Edwin Smith 2010-06-08 09:55:02 PDT
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?
Comment 19 James Sudduth 2010-06-08 10:00:45 PDT
Yes, that's correct.
Comment 20 James Sudduth 2010-06-14 15:48:11 PDT
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.
Comment 21 James Sudduth 2010-06-17 21:07:39 PDT
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
Comment 22 James Sudduth 2010-06-18 13:35:35 PDT
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).
Comment 23 Edwin Smith 2010-06-29 17:44:19 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.