Bugs item #1619130, was opened at 2006-12-19 15:22
Message generated for change (Comment added) made by treadway
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: Accepted
Priority: 3
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: Thomas Treadway (treadway)
Date: 2007-07-12 09:24
Message:
Logged In: YES
user_id=1541276
Originator: YES
Heads up, Apple said they WILL NOT port Carbon to 64-bit on Leopard.
----------------------------------------------------------------------
Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2007-07-12 08:32
Message:
Logged In: YES
user_id=580910
Originator: NO
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).
----------------------------------------------------------------------
Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2007-07-11 22: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 08: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
