[Pythonmac-SIG] Problems installing 32-bit Py-2.6.4 framework on 10.6.2

[Ned Deily]

[Resending, possibly lost in transit]

In article <1266809600.4b81fb00be931 at astrosun2.astro.cornell.edu>,
  Tom Loredo <loredo at astro.cornell.edu> wrote:
 > I've been attempting to install a 32-bit version of Python-2.6.4
 > on Snow Leopard 10.6.2.  I'd like to install it from source (a
 > 32-bit binary built for 10.3+ is at Python.org).  Unfortunately,
 > I haven't yet figured out a way to get an accessible 32-bit
 > interpreter built on Snow Leopard.

The python.org 2.6.4 is intended for 10.3.9 through 10.6.  If you want a
32-bit version, it should suit your needs just fine; there shouldn't be
any reason to build it yourself.

That said, if you really want to do so:

 > I have the latest SL Xcode installed, including the 10.4 SDK.
 > Here's what I've tried.
 >
 > Installing with the following configuration to build an
 > "intel" universal framework:
 >
 > $ ./configure --prefix=/usr/local/tmp --enable-framework
 > --with-universal-archs=intel --enable-universalsdk=/
 >
 > does indeed produce a universal Python with 32-bit (i386) and
 > 64-bit (x86_64) versions in a bundle, but there is no way to
 > access the 32 bit executable (the defaults variable that Apple
 > implemented to provide access to 32-bit 2.6.1 is proprietary and
 > has no effect on non-Apple installations; the Python.org solution
 > is to install a separate python-32 executable but this was not
 > backported to 2.6.4).

That will likely be fixed for 2.6.5 which is planned to be released in
mid-March.

 > So I've tried building an "all" universal binary, which should
 > produce ppc and intel versions of both bit-widths.

But that will have the same problem: on 10.6 in the absence of
additional application plist information, a 64-bit variant will be given
preference.  The pre-10.6 4-way universal scheme of producing
pythonxx-32 and pythonxx-64 variants also does not work on 10.6 without
modification.

 > $ ./configure --prefix=/usr/local/tmp --with-universal-archs=all
 > --enable-universalsdk=/
[...]
 > $ ./configure --prefix=/usr/local/tmp --enable-framework
 > --with-framework-name=Python32  --enable-universalsdk --with-
 > universal-archs=32-bit

Don't use --enable-universalsdk or --enable-universalsdk=/.  Always
specify the full path to the appropriate SDK.

This error:
 > (By the way, this produces a config error if I set
 > MACOSX_DEPLOYMENT_TARGET=10.6,

and this error:
 > #include_next <stdarg.h>

are caused by problems when the configure script implicitly selects the
wrong value for MACOSX_DEPLOYMENT_TARGET based on the value of
--enable-universalsdk.  You can avoid these errors by using the explicit
SDK path and explicitly setting MACOSX_DEPLOYMENT_TARGET.  Appropriate
combinations are:

        export MACOSX_DEPLOYMENT_TARGET=10.3
or    export MACOSX_DEPLOYMENT_TARGET=10.4
with .configure --enable-universalsdk=/Developer/SDKs/ 
MacOSX10.4u.sdk ...

export MACOSX_DEPLOYMENT_TARGET=10.5
.configure --enable-universalsdk=/Developer/SDKs/MacOSX10.5.sdk ...

export MACOSX_DEPLOYMENT_TARGET=10.6
.configure --enable-universalsdk=/Developer/SDKs/MacOSX10.6.sdk ...

 > Also, is there a way to build i386 without building ppc-32?

Probably not at the moment.  I think the only way on 10.6 is for
configure to set only -arch i386 and I don't think there is a way to
force that without modifying configure.  I'll make sure to check that
out before 2.6.5.

 > PS:  What is the role of MACOSX_DEPLOYMENT_TARGET?  Was it only a
 > one-time fix for Leopard installs that should be disregarded post- 
Leopard?

No.  MACOSX_DEPLOYMENT_TARGET indicates to gcc and friends what the
*minimum* OS X release level that the executable being produced should
be able to run on.   The python.org installers are intentionally built
this way so one installer image and executable will work on a range of
operations systems. (In some respects, python's needs are simpler than
most GUI applications which is why it can get away with specifying 10.3
while using the 10.4u SDK.)

 > I ask because NumPy does a check on its value.  I don't think
 > the check is consequential, but to avoid warning messages NumPy
 > installers are encouraged to set MACOSX_DEPLOYMENT_TARGET=10.6 for
 > Snow Leopard when installing NumPy.  I thought this was "inherited"
 > from Python itself.

I can't speak to what special things NumPy might do but, in general when
installing packages with conventional C extension modules, Distutils
will ensure that the same values for MACOSX_DEPLOYMENT_TARGET and for
the SDK will be used for C compiles as were used when building python
itself.

--
   Ned Deily
   nad at acm.org  --  []