[issue8089] 2.6/3.1 32-bit/64-bit universal builds always run in 64-bit on 10.6

[Tom Loredo]

Tom Loredo <loredo at 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 <report at bugs.python.org>
<http://bugs.python.org/issue8089>
_______________________________________