[Resending, possibly lost in transit]
In article <1266809600.4b81fb00be...@astrosun2.astro.cornell.edu>,
Tom Loredo <lor...@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
n...@acm.org -- []
_______________________________________________
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
