Ned Deily added the comment:
For 3.3.0, ./configure (configure.ac) was modified in 688d48e434e4 for
Issue13590 to use more appropriate defaults for universal builds on newer
releases. In particular, --enable-universalsdk=yes uses the Xcode default SDK
(as returned by xcodebuild) instead of the 10.4u SDK (not included with Xcode
4), --with-universal-archs now defaults to "intel" if ppc support is not
available, and MACOSX_DEPLOYMENT_TARGET defaults to the OS level for 10.6 and
newer systems (rather than using 10.4 or 10.3 by default). It also attempts to
avoid building Python with deprecated and problematic Apple llvm-gcc compiler,
using clang instead. The defaults can be overridden by providing explicit
arguments and/or environment variables to ./configure (--enable-universalsdk,
--with-universal-archs, CC, MACOSX_DEPLOYMENT_TARGET). While not 100% perfect,
the 3.3 changes give good defaults for nearly all common universal build
configurations on 10.4 through 10.8.
2.7.x and 3.2.x have the same problems; attached are patches that backport the
3.3 configure changes to them. However, they do introduce a potential
incompatibility. Currently, 2.7 and 3.2 initial configures set
MACOSX_DEPLOYMENT_TARGET by default to 10.4 (10.3 on a PPC system) for
non-universal builds or 32-bit universal builds and to 10.5 for other universal
builds. For 3.3, those values are still used for 10.4 and 10.5 systems; for
10.6 and later systems, the default deployment target is now the OS level
itself (10.6 for builds on 10.6, etc). Changing the default deployment target
for more recent systems has some benefits: the most obvious is that readline
support linking with the system BSD libedit is now enabled by default. The
potential incompatibility is that the deployment target value is used by
distutils.util.get_platform() to form the platform name which is used for bdist
names (like eggs) and the lib build directory for the standard library build.
While I haven't ve
rified that this is the case, if you've built Python 2.7.2, say, from source
on 10.6+ and installed some extension modules with Distutils, then would build
from a new release with the proposed patches and install to the existing
install location without reinstalling the extension modules, there might be a
chance of unexpected incompatibilities between the old extension module (built
to an older deployment target) and the upgraded interpreter. Perhaps somewhat
more likely is that an extension module binary distribution available on PyPI
was available for the old deployment target (10.4) but not for the new target
(10.6). Also, it is possible that differences in behavior might be introduced
by a change in default compiler. All of these potential incompatibilities can
be avoided by overriding the changed defaults, either at Python build time with
arguments to ./configure or at extension module build time with environment
variables or Distutils config files. Introducing such changes
is clearly acceptable with a new release, such as 3.3. For existing releases,
it can be argued that the newer, more appropriate settings can also be obtained
by just overriding the old defaults ("Explicit is better than implicit."). The
question then is, when the old default behavior no longer makes sense due to
changes outside of our control, do the benefits of changing them in a
maintenance release outweigh the risk of introducing an incompatibility?
If they are applied, some or all of the changes to the Mac/README file should
be backported as well. Also, while working on this, I did find one edge case
where the ./configure defaults do not produce a buildable configuration. The
case is on 10.6 with (the optional) Xcode 4. For universal builds, the test
added early in ./configure to determine if ppc is supported doesn't work.
Since the correct compiler hasn't been determined yet, the test looks at the
architectures in /usr/lib/libSystem.dylib. On 10.6, unfortunately, that (and
other libs) is a 3-way universal files (i386, x86_64, and ppc) even in the 10.6
SDK supplied with Xcode 4.2 for 10.6 despite the fact that the compilers
provided with 4.x do not support building ppc binaries. The problem shows up
right away as the "make" dies quickly and it is easily fixed by specifying
--with-universal-archs=intel. Still, it would be nice to fix that.
----------
keywords: +patch
stage: needs patch -> patch review
versions: +Python 2.7, Python 3.2
Added file: http://bugs.python.org/file28917/issue11485_backport_27.patch
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue11485>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
