Closed Bug 537817 Opened 10 years ago Closed 9 years ago
Tamarin does not build on Snow Leopard
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.
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.
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.
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.
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)
(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
gcc-4.2 is the default in SL + XC3.2.
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]
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)
Assignee: nobody → dschaffe
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Target Milestone: --- → flash10.2
Does anyone have a specific proposal to fix this?
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.
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
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
doh ignore comment 13, wrong bug
Assignee: dschaffe → jsudduth
Priority: -- → P1
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.
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?
The change was intentional based on my misunderstanding the fix proposal. I'll fix the patch.
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?
Yes, that's correct.
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.
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
Noticed a typo in tamarin-redux.py, argo.py and sandbox.py (a stray comma before the new --mac-sdk switch).
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+
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.