Tom Loredo <lor...@astro.cornell.edu> added the comment:
Attempted to build 2.6.5rc2 on Mac Pro (2006), OS 10.6.2, following
instructions in Mac/README:
./configure --prefix=/usr/local/tmp --enable-framework
--with-universal-archs=intel --enable-universalsdk=/
Results of "make test" are as expected from past experience (but what
architecture is being tested?):
332 tests OK.
2 tests failed:
test_asynchat test_smtplib
32 tests skipped:
test_al test_bsddb test_bsddb3 test_cd test_cl test_codecmaps_cn
test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr
test_codecmaps_tw test_curses test_dl test_epoll test_gl
test_imageop test_imgfile test_largefile test_linuxaudiodev
test_normalization test_ossaudiodev test_pep277 test_py3kwarn
test_smtpnet test_socketserver test_startfile test_sunaudiodev
test_timeout test_urllib2net test_urllibnet test_winreg
test_winsound test_zipfile64
1 skip unexpected on darwin:
test_dl
Notably, test_tcl passes without incident.
Running the following within the installation directory runs the 64-bit
pre-installation executable (judging by sys.maxint):
$ DYLD_FRAMEWORK_PATH=`pwd`: python.exe
Thus I presume it is the 64-bit version being run by "make test".
The installed IDLE still has the Tk new window freeze issue; sys.maxint
indicates it's the 32-bit version that is running when launcing IDLE. I have a
setup.py patch that will detect a 32-bit 10.6 installation and link against
Apple's Tcl/Tk-8.4 compatibility version if the user hasn't
installed their own Tcl/Tk frameworks, but it's an ugly hack and I'm not sure
this is desirable; we should probably just encourage installing newer Tcl/Tk.
The hack does produce a working 32-bit IDLE, however.
Running "python" on the command line runs the 32-bit version; is this intended?
I think the default behavior for universal builds should be documented in the
Mac/README, or at some location pointed to in the README.
I still see no way to access the two architectures. My ./configure installs
command line executables in /usr/local/tmp/bin, a non-existing directory before
the install. After installation, its contents are:
idle@ pydoc2.6@ python2.6@ pythonw2.6@
idle2.6@ python@ python2.6-config@ smtpd.py@
pydoc@ python-config@ pythonw@ smtpd2.6.py@
I was expecting something along the lines of python-32 and/or python-64 to be
here; what is the intended mechanism for accessing the two architectures?
$ arch -i386 python
gives me the (default) 32-bit version.
$ arch -x86_64 python
arch: posix_spawnp: python: Bad CPU type in executable
Whereas before with a universal install like this I was getting a 64-bit
default and no way to access 32-bit (IIRC), now I appear to be in the reverse
scenario.
Is there an error in my build process, or is there still an installation bug
for dual-architecture Intel installs?
----------
nosy: +tloredo
type: -> behavior
versions: +Python 2.6 -Python 3.1
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue8089>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
