Building Python 2.6.2 on Mac OS X 10.6 (final version, 10A432) fails. Full 
build transcript is attached.

Other system details: Xcode 3.2, hardware is MacPro1,1

This also applies to trunk, py3k and release31-maint.

For those trying to debug this, to silence the math.h warnings, set 
MACOSX_DEPLOYMENT_TARGET to 10.6 or something.

3k and trunk compile fine for me. Clean snow leopard install. My first 
suggestion is nuking macports.

2.6.2 maint compiles fine too - again, with a clean install of Snow 
Leopard, no macports.

Note that this problem appears to be x86_64-specific (caused by "-
arch_only i386"), and only happens if you configure with --enable-
framework.

As Jeese points out, there are suspicious signs of MacPorts in the log: 
"/opt/local/bin/ginstall -c -d -m 755 Python.framework/Versions/2.6"

Try removing all /opt/local entries from your $PATH and try again with
  export MACOSX_DEPLOYMENT_TARGET=10.6

The default value for the -arch flag changed in SL. It used to be the  
same as the output of the arch command (i386 on intel systems) and now  
is x86-64.

I'll create a patch for configure to automaticly detect the right value.

As a workaround you can build a universal build (--enable- 
universalsdk=/)

Noting for completeness that:
 * 3.0.1 behaves the same as 3.1.1 (works without --enable-framework).
 * 2.5.4 fails with 'cc1: error: unrecognized command line option "-Wno-
long-double"'. Once this is removed from the configure script, it then 
fails in mactoolboxglue.c due to missing Carbon functions, whether or 
not it was configured with --enable-framework. Using --disable-toolbox-
glue and not using --enable-framework allows the build to succeed. Using 
--disable-toolbox-glue and --enable-framework causes a failure involving 
struct rusage in posixmodule.c. Adding "#define _DARWIN_C_SOURCE" to 
pyconfig.h fixes this, but then there's the same "file is not of 
required architecture" failure seen in later versions.
 * 2.4.6 behaves the same as 2.5.4 apart from not needing the 
_DARWIN_C_SOURCE addition.
 * None of the failures are affected by /opt/local/bin's presence or 
absence in my PATH.

I'll note I am not doing framework builds, however people have run into 
problems with non framework builds and macports/old versions of gettext.

The attached patch (configure-in-sl.patch) fixes the build issue on SL,
I haven't committed the patch yet because it needs testing on 10.5/10.4.

NOTE: the patch touches configure.in without also patching configure. 
Therefore you need to run 'autoconf' after applying the patch.

NOTE2: the patch is for the trunk (2.7), I'll port the patch to the other 
branches (2.6, 3.2 and 3.1) after testing it on 10.5.

The patch works for me.  Thanks.

With the patch installed, no regressions were seen running my standard set 
of OSX installer builds/installs/regtests on 10.4 and 10.5.

This patch allows compiling, and forces everything to be x86_64. 
However, Python 2.6.2 still dies when attempting to install: 

cd Mac && make installmacsubtree DESTDIR=""
DYLD_FRAMEWORK_PATH=/tmp/Python-2.6.2:  ../python.exe 
./scripts/cachersrc.py -v 
/tmp/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/pyth
on2.6/plat-mac 
/tmp/opt/local/Library/Frameworks/Python.framework/Versions/2.6/Mac/Tool
s
Traceback (most recent call last):
  File "./scripts/cachersrc.py", line 44, in <module>
    main()
  File "./scripts/cachersrc.py", line 41, in main
    os.path.walk(dir, handler, (verbose, force))
  File "../Lib/posixpath.py", line 224, in walk
    func(arg, top, names)
  File "./scripts/cachersrc.py", line 23, in handler
    macresource.open_pathname(os.path.join(dirname, fn), 
verbose=verbose)
  File "/private/tmp/Python-2.6.2/Lib/plat-mac/macresource.py", line 81, 
in open_pathname
    refno = Res.FSpOpenResFile(pathname, 1)
AttributeError: 'module' object has no attribute 'FSpOpenResFile'
make[1]: *** [installmacsubtree] Error 1
make: *** [frameworkinstallmaclib] Error 2

This is both with MacPorts, and without MacPorts, in the path, just for 
those who were wary that this was solely a MacPorts issue. 

The reason it is dying is because a large number of the calls in Carbon 
are completely non-existant in 64-bit userspace. An example would be FSpOpenResFile as seen above. 

Apple issued a notice stating that many of these calls would not exist 
in Carbon 64-bit 
(http://developer.apple.com/mac/library/documentation/Carbon/Conceptual/
Carbon64BitGuide/Introduction/Introduction.html#//apple_ref/doc/uid/TP40
004381-CH1-SW1). 

What Apple apparently did for their shipped version of Python in Snow 
Leopard was a hack to combine 32-bit parts of Python for Carbon 32-bit 
support, and 64-bits. 
(http://www.opensource.apple.com/source/python/python-44/)

The only way I see currently to compile Python 2.6.2 natively on Mac OS 
10.6 (On a *64-Bit Capable* machine, this is critical) is to add the 
EXTRA_CFLAG "-m32" and patch Makefile.in, for two sections which 
completely ignore/don't include EXTRA_CFLAGS or PY_CFLAGS, or any 
CFLAGS. This pretty much limits you to a 32-bit version of Python. 
Because even doing "--host=i686-apple-darwin10 --target=i686-apple-
darwin10 --with-universal-archs=32-bit", since the default gcc target on 
a 64-bit capable machine is x86_64, it still produces x86_64 code in 
some areas.

By doing this, I was able to get Python 2.6.2 to compile *and* install. 
I'll submit a patch shortly, but the main issue is of course that 
plat_mac contains many 32-bit only references to the Carbon API. The 
true fix is to fix that area. But in the interim, you'll have to compile 
Python as 32-bit.

Also, the configure.in patch won't suffice for now, since you *can't* 
build a 64-bit version of Python on MacOSX from what I've seen, and also 
as reported by several other users on MacPorts.

My current plan is to fix this issue, and the issue of 64-bit universal 
builds on SL in the weekend. 

BTW. I'm not planning to fix this for 2.5 and 2.4, AFAIK both are no 
maintained beyond critical security patches.

On Thu, Sep 3, 2009 at 07:28, Ronald Oussoren<report@bugs.python.org> wrote:
>
> Ronald Oussoren <ronaldoussoren@mac.com> added the comment:
>
> My current plan is to fix this issue, and the issue of 64-bit universal
> builds on SL in the weekend.
>
> BTW. I'm not planning to fix this for 2.5 and 2.4, AFAIK both are no
> maintained beyond critical security patches.

That's correct.

Fixed in r74672 (trunk), r74681 (2.6), r74682 (3.x) and r74683 (3.1)

With the default configure flags you'll end up with a 64-bit build of 
Python on Snow Leopard, including a 64-bit copy of IDLE.

I tried release26-maint just now (r74683) and it errored out during make 
install. New log attached.

Could you retry the build after cleaning the target directory?

I've seem simular failures in the past and haven't been able to find the 
root cause of that problem.

Tried again after ensuring that ~/test was completely empty; no 
difference.

Should line 110 of Lib/plat-mac/macresource.py say 'isinstance' rather 
than 'instance'?

Looks like there's a spurious comma in line 110 of lib/plat-
mac/macresource.py in the release26-maint branch:

        if instance(arg, AttributeError), or arg[0] in (-37, -39):

You're right. I've fixed this in r74686.

It works now. Thanks!

The patch has one issue in the added AC_TRY_RUN ( 
http://svn.python.org/view/python/trunk/configure.in?
annotate=74672&pathrev=74672#l1542 ): it doesn't like the two [[...]] and 
main() needs a closing brace, }.  Otherwise, it fails on 10.5.8 (Xcode 
3.1.3, Intel) to properly detect 32bit vs 64bit (and if you look at 
config.log you should see complaints from around line 7065).

Attaching a patch which fixes it here.