Re: [Pythonmac-SIG] How to build Python 2.5 to support 64-bits on Mac OS X 10.4

2007-02-22 Thread Harold Walter Schranz
Hi Alex

Sorry for the delay in replying. I'll send a summary below based on  
our preliminary work achieved to date.

On 21/02/2007, at 7:22 AM, Alexandre Parenteau wrote:
> Any progress in this issue? I'm asked to investigate the same  
> thing. I would
> greatly appreciate hints on the configure options.

It is still early days (as information is relatively scarce and of  
variable reliability) and we have other multiple threads to our  
research project. This part of the project has been put on idle (not  
quite on the backburner, mixing metaphors). So progress so far is  
evident from the newsgroup threads:
http://mail.python.org/pipermail/pythonmac-sig/2007-February/ 
thread.html#18657

Particularly: http://mail.python.org/pipermail/pythonmac-sig/2007- 
February/018657.html

In summary:
> 6. However at the end of the process it appeared I had a 64-bit  
> executable of Python
>
> 1714:harry at jcs156218:~/Desktop/TODO/Python-2.5:599$ file python.exe
>
> python.exe: Mach-O 64-bit executable x86_64
>
> 1714:harry at jcs156218:~/Desktop/TODO/Python-2.5:599$ python.exe
>
> Python 2.5 (r25:51908, Feb  2 2007, 17:12:53)
> [GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
>  >>> 1+2
> 3
>
> So it looks like it is possible to produce a Mach-O 64-bit executable
> x86_64
> but whether it is working is another matter
>
> 7. Running the tests: make tests yields: in summary:
>
> 266 tests OK.
> 2 tests failed:
> 51 tests skipped:
> ...
> 17 skips unexpected on darwin:
> ...
> make: *** [test] Error 1
>
> I may try to repeat this process (with less flags?).
> At least this run is a lead that a 64-bit build of Python is possible.


Some detailed information and comments at:
http://lists.apple.com/archives/unix-porting/2007/Feb/index.html
http://lists.apple.com/archives/scitech/2007/Feb/msg0.html

I expect to make more progress when I have time to devote to the  
build. Just a few little details to tie up.

Let me know if you make any further progress. We too have to deal  
with Numpy and other packages (MySQL) with 64-bit issues.

Good Luck,
Harry.

 

Dr. Harold W. Schranz, Research Fellow, Computational Genomics Group
Division of Molecular Bioscience, John Curtin School of Medical Research
Australian National University, Canberra ACT 0200, Australia
 



___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig


Re: [Pythonmac-SIG] How to build Python 2.5 to support 64-bits on Mac OS X 10.4

2007-02-01 Thread Dr. Harold Walter Schranz
Hi Bill

Thanks for the comments ...
On 02/02/2007, at 12:39 PM, Bill Northcott wrote:

> On 01/02/2007, at 10:00 PM, Dr. Harold Walter Schranz wrote:
>> While the configure runs ... the make eventually fails with:
>>
>> /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)
>> make: *** [Python/mactoolboxglue.o] Error 1
>
> Your build is failing because it is trying to use Carbon which is  
> 32 bit only.  You either have to build without any GUI items which  
> should work or with rather more effort, you could probably build an  
> X-windows UNIX style 64bit build.  That would need 64 bit Xwindows  
> which is not supplied but can be built from the sources.  I have  
> not done it but I know some one who has.  There may even be a  
> binary around somewhere.  Since X communicates with its server via  
> a network socket one might get away with only some 64 bit  
> libraries, but I am not an expert on X.

Yes it confirmed what we already knew ... Tiger is not fully 64  
bit ... I'm trying to avoid the GUI (and any other 32 bit items) to  
produce a clean command line version of python 2.5 which is 64 bit.

> Is it really worth all the hassle when Leopard is going to be out  
> in a few months??

Yes ... we need to have 64 bit functionality on our research server  
(Xserve Quad Xeon) for a large genomic database (I mean big ... small  
files in the gigabyte range ... many much bigger). Should we twiddle  
our thumbs and wait for Leopard ... h ... talk to our group  
leader ... research projects can ill afford to stand still for  
months. Eventually, when available (via ADC) alternatively a Leopard  
Preview Install might be a worthy investment.

Have a Good Weekend,
Harry.


 

Dr. Harold W. Schranz, Research Fellow, Computational Genomics Group
Division of Molecular Bioscience, John Curtin School of Medical Research
Australian National University, Canberra ACT 0200, Australia
 



___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig


Re: [Pythonmac-SIG] How to build Python 2.5 to support 64-bits on Mac OS X 10.4

2007-02-01 Thread Dr. Harold Walter Schranz
G'Day Gentle Programming Folk,

Thanks for the help so far ... I would appreciate any further  
comments or help.

I'm still on the quest to produce a 64 bit non-framework command-line  
version of Python 2.5 on the Mac Intel platform (e.g. Intel Core 2  
Duo and Xserve).

A little bit of non-virtuoso hand tuning ... caveat emptor ... I need  
to repeat the whole process and see if this chicken flies  
reproducibly ...

My logic (or rather a protocol plucked from the aether, enigmatic  
thus un-refutable ...) ... (this process reminds me of my ANUSF HPC  
porting days) follows below.


1. With what I thought (but the machine though otherwise) was a  
worthy combination of semi-random flags:

./configure --disable-framework --disable-toolbox-glue \
OPT="-fast -arch x86_64 \
-Wall -Wstrict-prototypes -fno-common -fPIC" \
LDFLAGS="-arch x86_64"

The make bombs finally at the posixmodule.c

gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused- 
madd -DNDEBUG -fast -arch x86_64 -Wall -Wstrict-prototypes -fno- 
common -fPIC  -I. -I./Include   -DPy_BUILD_CORE  -c ./Modules/ 
posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c: In function 'posix_setpgrp':
./Modules/posixmodule.c:3590: error: too many arguments to function  
'setpgrp'
make: *** [Modules/posixmodule.o] Error 1



2. Closer examination of posixmodule.c reveals the section of code  
around line 3590:

#ifdef HAVE_SETPGRP
PyDoc_STRVAR(posix_setpgrp__doc__,
"setpgrp()\n\n\
Make this process a session leader.");

static PyObject *
posix_setpgrp(PyObject *self, PyObject *noargs)
{
#ifdef SETPGRP_HAVE_ARG
 if (setpgrp(0, 0) < 0)<-- Line 3590
#else /* SETPGRP_HAVE_ARG */
 if (setpgrp() < 0)
#endif /* SETPGRP_HAVE_ARG */
 return posix_error();
 Py_INCREF(Py_None);
 return Py_None;
}

#endif /* HAVE_SETPGRP */

In line 3590,  setpgrp(0, 0) has 2 arguments, whereas elsewhere   
setpgrp() has no arguments ...
this perhaps upsets the compiler (with the given flags, maybe there  
are looser flags?)



3. To overcome this obstacle, I tried a kludge ...

I noticed that pyconfig.h (Configuration header file) as created by  
configure (with the flags used above in step 1) had the line:

./pyconfig.h:#define SETPGRP_HAVE_ARG 1

though the pyconfig.h.in file  (Source from which pyconfig.h is  
created (GNU autoheader output)) had this feature turned off:

./pyconfig.h.in:#undef SETPGRP_HAVE_ARG

Apparently  there are two versions of setpgrp - one with arguments  
(Sys V heritage) and one without (BSD heritage)?
I think a FAQ discussion on A/UX about setpgrp might be related  
(http://www.faqs.org/faqs/aux-faq/part2/).



4. I edited pyconfig.h manually to turn off the flag SETPGRP_HAVE_ARG  
(I commented out the SETPGRP_HAVE_ARG 1 and undefined SETPGRP_HAVE_ARG)

/* Define if setpgrp() must be called as setpgrp(0, 0). */
/* #define SETPGRP_HAVE_ARG 1 */
#undef SETPGRP_HAVE_ARG


5. I the ran make which spat out a few warnings and errors: e.g.
...
In file included from /Users/harry/Desktop/TODO/Python-2.5/Modules/ 
_ctypes/_ctypes.c:110:
build/temp.macosx-10.3-i386-2.5/libffi/include/ffi.h:161: error:  
parse error before 'ffi_abi'
build/temp.macosx-10.3-i386-2.5/libffi/include/ffi.h:161: warning: no  
semicolon at end of struct or union
...
ld64 warning: in /System/Library/Frameworks//CoreFoundation.framework/ 
CoreFoundation, missing required architecture x86_64 in file
*** WARNING: renaming "_locale" since importing it failed: dlopen 
(build/lib.macosx-10.3-i386-2.5/_locale.so, 2): Symbol not found:  
_CFStringGetSystemEncoding
   Referenced from: build/lib.macosx-10.3-i386-2.5/_locale.so
   Expected in: dynamic lookup
...
ld64 warning: in /usr/lib/libsqlite3.dylib, missing required  
architecture x86_64 in file
*** WARNING: renaming "_sqlite3" since importing it failed: dlopen 
(build/lib.macosx-10.3-i386-2.5/_sqlite3.so, 2): Symbol not found:  
_sqlite3_close
   Referenced from: build/lib.macosx-10.3-i386-2.5/_sqlite3.so
   Expected in: dynamic lookup
...
ld64 warning: in /System/Library/Frameworks//Tcl.framework/Tcl,  
missing required architecture x86_64 in file
ld64 warning: in /System/Library/Frameworks//Tk.framework/Tk, missing  
required architecture x86_64 in file
*** WARNING: renaming "_tkinter" since importing it failed: dlopen 
(build/lib.macosx-10.3-i386-2.5/_tkinter.so, 2): Symbol not found:  
_Tcl_Merge
   Referenced from: build/lib.macosx-10.3-i386-2.5/_tkinter.so
   Expected in: dynamic lookup



6. However at the end of the process it appeared I had a 64-bit  
executable of Python

1714:[EMAIL PROTECTED]:~/Desktop/TODO/Python-2.5:599$ file python.exe

python.exe: Mach-O 64-bit executable x86_64

1714:[EMAIL PROTECTED]:~/Desktop/TODO/Python-2.5:599$ python.exe

Python 2.5 (r25:51908, Feb  2 2007, 17:12:53)
[GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> 1+2
3

So it looks l

[Pythonmac-SIG] How to build Python 2.5 to support 64-bits on Mac OS X 10.4

2007-02-01 Thread Dr. Harold Walter Schranz
Hi Distinguished Pythoneers,

Sorry if this Email is too verbose or unstructured ... (blame: blood  
sugar is dropping and I'm in need of some dinner!)

I've been set the task of creating a 64 bit Intel build of Python 2.5  
that supports the EM64T functionality in our research groups new  
machines which are both running OS X 10.4.8.

Intel Core 2 Duo laptop:
   Machine Name:Mac  Machine Model: MacBookPro2,2
   Processor Name:  Intel Core 2 Duo   Processor Speed: 2.33 GHz   
Number Of Processors:   1 Total Number Of Cores:2
   L2 Cache (per processor):4 MB  Memory:   2 GB  Bus Speed:667 MHz

Xserve Quad Xeon:
   Machine Name:Xserve  Machine Model:  Xserve1,1
   Processor Name:  Dual-Core Intel Xeon  Processor Speed:  3 GHz   
Number Of Processors:   2  Total Number Of Cores:   4
   L2 Cache (per processor):4 MB  Memory:   16 GB  Bus Speed:   1.33 GHz

The usual Python 2.5 build (http://www.python.org/ftp/python/2.5/ 
python-2.5-macosx.dmg) I believe is just 32 bit Universal ... we  
don't need a Universal build but 32 bits just doesn't cut it (the  
proverbial mustard) so to speak.

I believe just a command line Python would be fine that supports 64  
bit (as we need to interface to a MySQL database with multi-gigabytes  
of data).

So far we've tried a source base build (http://www.python.org/ftp/ 
python/2.5/Python-2.5.tgz)

1) with the default configure (default options) which just leads to a  
32 bit Intel python executable:

$ file python.exe
python.exe: Mach-O executable i386


  2) and then a few different flags on configure (I've no idea where  
my "partner in crime" got these from! I though -march was the new  
flag!):
/configure OPT="-fast -Wall \
 > -Wstrict-prototypes -fno-common -fPIC \
 > -isysroot /Developer/SDKs/MacOSX10.4u.sdk \
 > -arch x86_64" \
 > LDFLAGS="-Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk,\
 > -headerpad_max_install_names -arch x86_64"

While the configure runs ... the make eventually fails with:

/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)
make: *** [Python/mactoolboxglue.o] Error 1

I've seen this SIGDIGLEN error about before ... probably relates to  
the conditional in fp.h not handling an unknown CPU_TARGET :
#if TARGET_CPU_PPC || TARGET_CPU_X86
 #define SIGDIGLEN  36
#elif TARGET_CPU_68K
 #define SIGDIGLEN  20
#endif

Anyway, I expect the fundamental problem relates to Carbon not being  
64-bit ready (until Leopard).

I guess I just want to do a basic ("Unix-"-y) command line build of  
Python 2.5 that handles the EM64T functionality in the chips we have  
in our machines.

Do I have to wait until Leopard???

Thanks for any pointers (or any other structures 8-) ).

Harry.
Extinguished Pythoneer (temporarily)

 

Dr. Harold W. Schranz, Research Fellow, Computational Genomics Group
Division of Molecular Bioscience
John Curtin School of Medical Research
Australian National University
Canberra ACT 0200, AustraliaEmail:  
[EMAIL PROTECTED]
 




___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig