Ned Deily n...@acm.org added the comment:
Explicitly defining CC during the installer build does seem to fix the
extension build problem, at least for well-behaved extensions. I
successfully tested building simplejson (using both easy_install and
direct setup.py installs) and MySQLdb, both
Ronald Oussoren ronaldousso...@mac.com added the comment:
It should be possible to tweak distutils to do the right thing for
upcoming releases, distutils already contains some special code to allow
building extensions for a univeral build on 10.3.9 (where the compiler
doesn't support
Ned Deily n...@acm.org added the comment:
Tweaking distutils as you propose sounds like a good idea to help with
future releases. Also, the proposed installer variant to support 64-bit
would not have this problem as it would only work with 10.5 and above.
(Perhaps there's a warning in all
Ronald Oussoren ronaldousso...@mac.com added the comment:
There is a much easier solution for the 2.6.3 release: ensure that CC=gcc-
4.0 when building the installer.
That requires minimal changes to the build machinery and should be safe
enough.
The only change to distutils I do want to make
Ronald Oussoren ronaldousso...@mac.com added the comment:
r75022 (trunk) and r75023 (2.6) add the other half of my proposal:
distutils will ignore -isysroot SDKPATH when SDKPATH is not present on the
current system.
That combined with explicit compilation using gcc-4.0 should solve these
New submission from Ned Deily n...@acm.org:
Potential 2.6.3 release blocker
On OS X 10.6 (Snow Leopard), if you attempt to install a package with a
extension module using a Python from a python.org OS X installer (say,
2.6.x or 3.1.x), the c compilation steps will likely fail in one of two
Changes by Ned Deily n...@acm.org:
--
nosy: +barry
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6957
___
___
Python-bugs-list mailing list
