[Numpy-discussion] Compiling NumPy on Windows for Python 3.3 with MSVC 2010

Christoph Gohlke cgohlke at uci.edu
Thu Nov 15 13:15:35 EST 2012

On 11/15/2012 6:24 AM, Peter Cock wrote:
> 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:
>>> http://mail.scipy.org/pipermail/numpy-discussion/2012-June/062866.html
>>> Any tips?
>>> Peter
>> Try changing line 648 in Python33\Lib\distutils\msvc9compiler.py to
>> `mfinfo = None`.
>> http://hg.python.org/cpython/file/tip/Lib/distutils/msvc9compiler.py#l648
>> Christoph
> Hi Christoph,
> 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?
> Thanks,
> Peter

Naturally the file would be named msvc10compiler.py but the name may be 
kept for compatibility reasons. AFAIK msvc10 does not use manifests any 
longer for the CRT dependencies and all the code handling msvc9 
manifests could be removed for Python 3.3. I have been building 
extensions for Python 3.3 with msvc10 and this distutils patch for some 
months and did not notice any issues.


More information about the NumPy-Discussion mailing list