Prior to r79392 (trunk) and r79401 (py3k), the changes introduced for Issue8211, the gcc lines produced for an OS X universal build, say

./configure --enable-universalsdk --with-universal-archs=32-bit ; make

might look like this:

gcc-4.0 -c -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk  -fno-common -dynamic -DNDEBUG -g -O3 -I/tmp/_py/libraries/usr/local/include  -I. -IInclude -I/private/tmp/_t/Include -isysroot /Developer/SDKs/MacOSX10.4u.sdk  -DPy_BUILD_CORE -o Modules/python.o /private/tmp/_t/Modules/python.c

With the changes introduced by r79392 and r79401 to save and restore the original value of CFLAGS across the AC_PROG_CC macro call (see trunk configure.in at about line 496), the same gcc call now looks like this:

gcc-4.0 -c -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk  -fno-common -dynamic -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk  -DNDEBUG -g -O3 -I/tmp/_py/libraries/usr/local/include  -I. -IInclude -I/private/tmp/_t/Include -isysroot /Developer/SDKs/MacOSX10.4u.sdk  -DPy_BUILD_CORE -o Modules/python.o /private/tmp/_t/Modules/python.c

Note that there are now two sets of -arch and -sysroot flags because the CFLAGS ones were being lost before but are now preserved.  While the duplicate flags do not seem to bother gcc and friends, the code in sysconfig.py to determine the machine name for OS X is not prepared to handle them and the build fails when the interpreter starts up:

Traceback (most recent call last):
  File "/private/tmp/_t/Lib/site.py", line 542, in <module>
    main()
  File "/private/tmp/_t/Lib/site.py", line 521, in main
    addbuilddir()
  File "/private/tmp/_t/Lib/site.py", line 118, in addbuilddir
    s = "build/lib.%s-%.3s" % (get_platform(), sys.version)
  File "/private/tmp/_t/Lib/sysconfig.py", line 646, in get_platform
    "Don't know machine value for archs=%r"%(archs,))
ValueError: Don't know machine value for archs=('i386', 'i386', 'ppc', 'ppc')
make: *** [sharedmods] Error 1

I tried to reproduce it on trunk by trying,
./configure --enable-universalsdk --with-universal-archs=32-bit ; make
However It did managed to build successfully.

The relevant bits during installation:

gcc -c -arch ppc -arch i386 -isysroot /   -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes  -I. -IInclude -I./Include   -DPy_BUILD_CORE -o Modules/python.o ./Modules/python.c

<snip>

Python build finished, but the necessary bits to build these modules were not found:
bsddb185           gdbm               linuxaudiodev   
ossaudiodev        readline           spwd            
sunaudiodev                                           
To find the necessary bits, look in setup.py in detect_modules() for the module's name.

Failed to build these modules:
_bsddb             _locale                            

running build_scripts
<trim>
/usr/bin/install -c -m 644 ./Tools/gdb/libpython.py python.exe-gdb.py

12:52:55 l0nwlf-MBP:python-svn $ ./python.exe 
Python 2.7b1+ (trunk:79945M, Apr 11 2010, 12:46:28) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>

Fails for me with py3k, trunk, and with the 2.7.b1 tarball on 10.6.3 (Intel) and 10.5.8 (ppc).

Your test output looks suspect; with the given configure values, the use of gcc-4.0 should be forced.  Perhaps you used an existing build directory but did not do a make clobber and/or not rm the previous cached configure values?

I reinstalled with :
make distclean; ./configure --enable-universalsdk --with-universal-archs=32-bit; make
on 10.6.2 (Intel) Which I guess is correct.

Chances are you do not have the 10.4u SDK installed; it is not installed by default by the Snow Leopard Xcode mpkg installer.  If it is not installed, configure falls back to using / as the sysroot (see configure.in at around line 95).  If you are going to build and test Python on OS X 10.5 or 10.6, you really need to have it installed.

$ ls /Developer/SDKs/
MacOSX10.4u.sdk/ MacOSX10.5.sdk/  MacOSX10.6.sdk/

Even without 10.4u installed, this should fail:

make distclean; ./configure --enable-universalsdk=/Developer/SDKs/MacOSX10.6.sdk --with-universal-archs=32-bit MACOSX_DEPLOYMENT_TARGET=10.6

The error was finally reproduced with :
$make distclean; ./configure --enable-universalsdk=/Developer/SDKs/MacOSX10.6.sdk --with-universal-archs=32-bit MACOSX_DEPLOYMENT_TARGET=10.6; make 

gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.6.sdk  -u _PyMac_Error -o python.exe \
			Modules/python.o \
			libpython2.7.a -ldl  -framework CoreFoundation     
Traceback (most recent call last):
  File "/Volumes/CoreHD/python-svn/Lib/site.py", line 544, in <module>
    main()
  File "/Volumes/CoreHD/python-svn/Lib/site.py", line 523, in main
    addbuilddir()
  File "/Volumes/CoreHD/python-svn/Lib/site.py", line 118, in addbuilddir
    s = "build/lib.%s-%.3s" % (get_platform(), sys.version)
  File "/Volumes/CoreHD/python-svn/Lib/sysconfig.py", line 646, in get_platform
    "Don't know machine value for archs=%r"%(archs,))
ValueError: Don't know machine value for archs=('i386', 'i386', 'ppc', 'ppc')
make: *** [sharedmods] Error 1

Also,
$ ls /Developer/SDKs/
MacOSX10.5.sdk MacOSX10.6.sdk

It seems to that improvement for CFLAGS show bug  in python build system - quote for configure:
....
		BASECFLAGS="${UNIVERSAL_ARCH_FLAGS} -isysroot ${UNIVERSALSDK} ${BASECFLAGS}"
		tgt=`sw_vers -productVersion | sed 's/\(10\.[[0-9]]*\).*/\1/'`
		if test "${UNIVERSALSDK}" != "/" -a "${tgt}" '>' '10.4' ; then
			CFLAGS="${UNIVERSAL_ARCH_FLAGS} -isysroot ${UNIVERSALSDK} ${CFLAGS}"
			CPPFLAGS="-isysroot ${UNIVERSALSDK}"
		fi
....
No idea why the script set CFLAGS and CPPFLAGS under a specific condition - may be some test cases from configure will fail without those flags set.
Assignment to CPPFLAGS will ignore user settings - this is not acceptable.

Lets see report from Ned Deily: "might look like this" : the -isysroot is added twice .

Setting CPPFLAGS to include the SDK is needed to make sure some of the autoconf tests work correctly by using the SDK's header files rather than  those from /.  But, you're right, it shouldn't throw away other CPPFLAGS settings. Plus that whole test there is suspect: it probably shouldn't be testing the build system version there.  There are various ways to handle this and opportunities to simplify the OS X SDK processing; plus all of the trees (trunk, py3k, 26, 31) should work the same way.  Let's see what Ronald prefers.

Setting CPPFLAGS is needed to ensure that the configure tests use the correct header files, as Ned noted.

I agree that this should be cleaned up, I also agree with MAL's comment in Issue8211: the entire machinery for setting up the compiler in Python's configure script is a mess.

I'll see what can be done to fix this issue.

This problem is caused by this bit in Makefile.pre.in:

OPT=            @OPT@
BASECFLAGS=     @BASECFLAGS@
CFLAGS=         $(BASECFLAGS) @CFLAGS@ $(OPT) $(EXTRA_CFLAGS)


There both 'BASECFLAGS' and 'CFLAGS' get patched in from configure.in, while the intention of the configure script always was that only BASECFLAGS gets set from configure CFLAGS. 


BTW. I always test with a build directory separate from the source directory, that makes it a lot easier to ensure that you have a clean environment:

$ mkdir build
$ cd build
$ ../configure ....


I'm currently testing a fix that only sets CFLAGS and CPPFLAGS and will apply that if this results in a valid build.


Adding 2.6 and 3.1 to the list of versions because those also have the same change to Makefile.pre.in

Btw. this issue is caused by the fix for issue 1628484.

This should now be fixed:

* r80187 (trunk)
* r80188 (2.6)
* r80191 (3.2)
* r80192 (3.1)

The fix is not ideal, there's still two '-isysroot' flags in the compiler command-line, but at least everything compiles and works again.