Bugs item #1619130, was opened at 2006-12-20 00:22 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1619130&group_id=5470
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Thomas Treadway (treadway) >Assigned to: Ronald Oussoren (ronaldoussoren) Summary: 64-bit Universal Binary build broken Initial Comment: 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 ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2007-07-12 07:51 Message: Logged In: YES user_id=580910 Originator: NO 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. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2007-01-03 17:08 Message: Logged In: YES user_id=21627 Originator: NO You are right: four-way universal builds are not supported currently. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1619130&group_id=5470 _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com