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