Hi,
I'm running into problem building a 4-way universal binary of python.
The following has cropped up on both python2.5 and python2.4.2

The configure goes OK, but the make bombs.
[2244]$  ./configure --prefix=$VISITPATH/python OPT="-fast -Wall \
-Wstrict-prototypes -fno-common -fPIC \
-isysroot /Developer/SDKs/MacOSX10.4u.sdk \
-arch ppc -arch i386 -arch ppc64 -arch x86_64" \
LDFLAGS="-Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk,\
-headerpad_max_install_names -arch ppc -arch i386 \
-arch ppc64 -arch x86_64"

. . .
[2245]$ make
gcc -c -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -fast -Wall -Wstrict-prototypes -fno-common -fPIC -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386 -arch ppc64 -arch x86_64  -I. -I./Include   -DPy_BUILD_CORE -o Modules/python.o ./Modules/python.c
In file included from ./Include/Python.h:57In file included from ./Include/Python.h:57,
                 from ./Modules/python.c:3:
./Include/pyport.h:730:2: error: #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)."
,
                 from ./Modules/python.c:3:
./Include/pyport.h:730:2: error: #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)."
lipo: can't figure out the architecture type of: /var/tmp//ccL3Ewl4.out
make: *** [Modules/python.o] Error 1

Comenting out the "#error" statement in pyport.h get me a little further
befor getting:
gcc -c -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -fast -Wall -Wstrict-prototypes -fno-common -fPIC -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386 -arch ppc64 -arch x86_64  -I. -I./Include   -DPy_BUILD_CORE -o Python/mactoolboxglue.o Python/mactoolboxglue.c
In file included from /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/DriverServices.h:32,
                 from /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/CarbonCore.h:125,
  . . .
                 from /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/Carbon.framework/Headers/Carbon.h:20,
                 from ./Include/pymactoolbox.h:10,
                 from Python/mactoolboxglue.c:27:
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/fp.h:1338: error: 'SIGDIGLEN' undeclared here (not in a function)
lipo: can't figure out the architecture type of: /var/tmp//ccEYbpTz.out
make: *** [Python/mactoolboxglue.o] Error 1

Seem Carbon doesn't support 64-bits!
Is there a solution?
   trt
--
Thomas R. Treadway
Computer Scientist
Lawrence Livermore Nat'l Lab
7000 East Avenue, L-159
Livermore, CA 94550-0611

You are right: four-way universal builds are not supported currently.

Even two-way universal builds aren't supported in 64-bit mode.  Non-universal 64-bit builds do work properly, the problem with 2-way universal 64-bit builds is that not all features that configure detects are the same on x86_64 and ppc64, the only one I've found so far is VA_LIST_IS_ARRAY (defined on one architecture but not the other).

I'll pobably fix that soonish, 4-way universal builds will be more work although mostly in thinking about the right policies and especiall this issue:

Will distutils in a 4-way universal build default to building? If yes, how will users be able to specify that an extension should be build in 32-bit mode only? If no, how does one build 64-bit extensions?

I'm currently leaning towards:
- Default to 32-bit only on Tiger and 4-way on Leopard
- Patch build_ext and/or Extension to enable overriding the default without fiddling with CFLAGS/LDFLAGS (or there equivalents in distutils)

(This is for a 4-way universal build only, 2-way universal builds and non-universal builds will keep behaving as they do now). 

BTW. 64-bit builds on any released version of OSX don't have access to anything but libSystem, which means: no GUI code and no access to Apple frameworks in general.  This will change in Leopard (see Apple's website for that), but as this OS is still under NDA I won't comment on the details.

Asssinged this bug to myself because I'm more likely to fix this than Jack is.

I now have a fairly clear strategy for the C bits. I will upload a patch when I have a complete working solution (including testing). I can't test right now because I'm at EuroPython and don't have access to a PPC64 machine from here.

An overview of the changes:
- Introduce a new header file: Include/pymacconfig.h

   This header file does compile-time detection of a number of variables (such a VA_ARG_IS_LIST and SIZEOF_VOID_P) that are no longer configure-time constants but only compile-time ones. This also surpressed the toolbox glue feature macro in 64-bit mode.

- Patch setup.py to avoid compiling the Carbon wrappers and the toolbox glue in 64-bit mode, while still compiling them in 32-bit mode when building a 32-bit/64-bit hybrid.

- mactoolboxglue.c contains some Carbon code outside of the block that's guarded by the feature macro. Also disable that.

Python with these patches still builds and passes the test suite, both in 32-bit and 64-bit mode and with --enable-toolboxglue.

I hope to prepare a patch with a full solution when I get back from Europython. 

NOTE: More work is needed once Leopard is released because the promised features of that include 64-bit support throughout the systems. Some of that work is non-trivial (see http://www.python.org/sf/779153).

Heads up, Apple said they WILL NOT port Carbon to 64-bit on Leopard.

Heads up, Apple said they WILL NOT port Carbon to 64-bit on Leopard.

treadway: do you have a reference to that?

BTW. I have (legal) access to Leopard prereleases, but these are under NDA.

Anyway, if you're right that just means I won't have to do more work after Leopard is released. We'll see...

I've seen a few references in mail list.
I believe Apple is keeping it quiet. Cocoa will be the only 64-bit GUI
At WWDC07.
It was alluded to at the Mac OS X State of the Union, then explicitly stated by engineers in one of the sessions.
The anouncement up set quite a few developers.

This should be fixed on the trunk, I've introduced a new configure option 
that makes it possible to build a 4-way universal build on OSX 10.5

Note that the default build will still be a 2-way universal build that 
runs on 10.3.9 and later.

No complaints were voiced, so I'm closing this.