On 7 Aug, 2008, at 20:16, Chris Kees wrote:
Hi,
I'm trying to rebuild my 4-way universal framework build of python
2.6 using the latest revision in the trunk. I got a compile error
due to a redefinition of FSIORefNum in some of the Mac/Modules files
(see svn diff output at end of email). After changing that, I
still get a problem running 'make test' at 'test_array'. My machine
starts grinding away and the resident memory of the python process
goes through the roof.
I have the same problems when testing, that's due to exterme memory
usage in the testset. I had to reset my machine the last time I tried
to run the tests. At least one test creates a list a very large numer
of elements (look for test_overflow in Lib/test/test_list.py).
I went ahead and tried 'make install' anyway, and got the problem
below, which looks like a simple error in a config file. Has
anybody seen these problems or have any suggestions? I may just need
to roll it back to Ronald's revision (63955), but I thought I would
try a more recent version.
For some reason configure doesn't seem to have detected that the 10.5
SDK. Are you building on OSX 10.5? If so, could you check pyconfig.h
to check if HAVE_MACOS105_SDK is defined? (Which it should be when
you're building a 4-way universal binary).
Reverting to the 63955 version wouldn't be helpful in this case, the
typedef on the trunk is needed to ensure that the code compiles on 10.4.
BTW. I build the 4-way universal framework using:
mkdir build64
../configure --with-universal-archs=all --with-framework-
name=Python64 --enable-framework --enable-universalsdk=/
make
make install
The --with-framework-name option is optional and allows you to have
both a regular 32-bit build and a 4-way universal build (which is
helpful while testing).
Thanks,
Chris
python-trunk/build: arch -386 -ppc ../python.exe ../../Mac/scripts/
cachersrc.py -v /Library/Frameworks/Python64.framework/Versions/2.6/
lib/python2.6/plat-mac /Library/Frameworks/Python64.framework/
Versions/2.6/Mac/Tools
arch: Unknown architecture: 386
That's a real bug, that should be "-i386" instead of "-386".
I've just commited a fix for this (rev. 65652).
To anyone that is interested in a 4-way build: please test this
configuration, the 2.6 release is getting closer and hence there is
little time left to get bugfixes into the repository.
Index: Mac/Modules/MacOS.c
===================================================================
--- Mac/Modules/MacOS.c (revision 65574)
+++ Mac/Modules/MacOS.c (working copy)
@@ -30,10 +30,6 @@
#include <Carbon/Carbon.h>
#include <ApplicationServices/ApplicationServices.h>
-#ifndef HAVE_MACOS105_SDK
-typedef SInt16 FSIORefNum;
-#endif
-
static PyObject *MacOS_Error; /* Exception MacOS.Error */
#define PATHNAMELEN 1024
Index: Mac/Modules/file/_Filemodule.c
===================================================================
--- Mac/Modules/file/_Filemodule.c (revision 65574)
+++ Mac/Modules/file/_Filemodule.c (working copy)
@@ -7,10 +7,6 @@
#include "pymactoolbox.h"
-#ifndef HAVE_MACOS105_SDK
-typedef SInt16 FSIORefNum;
-#endif
-
/* Macro to test whether a weak-loaded CFM function exists */
#define PyMac_PRECHECK(rtn) do { if ( &rtn == NULL ) {\
PyErr_SetString(PyExc_NotImplementedError, \
_______________________________________________
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
_______________________________________________
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
