[Numpy-discussion] Compiling NumPy on Windows for Python 3.3 with MSVC 2010
p.j.a.cock at googlemail.com
Thu Nov 15 09:24:28 EST 2012
On Wed, Nov 14, 2012 at 7:35 PM, Christoph Gohlke <cgohlke at uci.edu> wrote:
>> RuntimeError: Broken toolchain: cannot link a simple C program
>> It appears a similar issue was raised before:
>> Any tips?
> Try changing line 648 in Python33\Lib\distutils\msvc9compiler.py to
> `mfinfo = None`.
That was very precise advice and seems to solve this. Presumably
you've faced something like this before. Is there an open issue for
this in Python itself?
Line 648 didn't seem sensible (and I guess the tip has changed), but
I tried replacing this bit of Python33\Lib\distutils\msvc9compiler.py
which was near by:
# embed the manifest
# XXX - this is somewhat fragile - if mt.exe fails, distutils
# will still consider the DLL up-to-date, but it will not have a
# manifest. Maybe we should link to a temp file? OTOH, that
# implies a build environment error that shouldn't go undetected.
mfinfo = self.manifest_get_embed_info(target_desc, ld_args)
with your suggestion of 'mfinfo = None', and this did seem enough
to get NumPy to compile with Python 3.3 and MSCV v10. I could
then build and test a library using NumPy (C and Python APIs), but
I've not yet installed nose to run NumPy's own tests.
Looking at the code for the manifest_get_embed_info method,
I don't see any obvious 9 vs 10 issues like the problems I hit
before. However there are some regular expressions in the
method _remove_visual_c_ref which it calls which look more
likely - looking for two digits when perhaps it needs to be three
under MSVC 10...
As a general point, if MSVC 10 is sufficiently different from 9,
does it make sense to introduce distutils/msvc10compiler.py
(subclassing/reusing most of distutils/msvc9compiler.py) in
Python itself? Or in NumPy's distutils?
More information about the NumPy-Discussion