python 2.6, MS manifest and distutils

[David Cournapeau]

Hi,

I am trying to make numpy build with python 2.6 on windows, and it has
been a bumpy road. Building with MS tools works OK, but building with
mingw is still problematic. The problems are linked to manifest, and
msvcr versions issues. Here is my understanding and how far I got:

- python 2.6 is built with VS 2008, and msvcr 9: numpy has to be
built against the exact same runtime to work.
- msvcr 9 is not publicly available on most computers (by publicly, I
mean system-wide), but python 2.6 installs its own version in the Side
by Side assembly folder.
- I can build a trivial extension with mingw which can be loaded by
python 2.6, by embedding manifest with gcc + windres (that is by using
a toolchain 100 % mingw-based, without using any MS tool like mt.exe).

The problems:
- numpy, at the configuration stage, builds some small code snippets
and run them: to run, they have to embed manifests as well. I think
this should be somewhat supported by distutils ?
- which manifest file to use: for now, I am using a manifest file
copied from the python binary itself (using strings on python.exe). It
works, but I guess this means that the extensions are specific to
this exact binary: python 2.6 reports the version 9.0.21022.8, the MS
runtime in redist directory of my copy of visual studio 2008 express
reports 9.0.30729.1. If python 2.6.1 is built with another version, am
I right to assume it will break (because it would use two different
runtimes) ? Would it makes sense to make the exact version of the
runtime available to distutils so that we can generate manifest on the
fly for mingw ?

Thanks,

David

 

[Martin v. Löwis]

- msvcr 9 is not publicly available on most computers (by publicly, I

mean system-wide), but python 2.6 installs its own version in the Side
by Side assembly folder.

Almost. If you chose "just for me", then it doesn't put the CRT into
SxS, but just places msvcr9.dll next to python26.dll (plus a manifest
file).

- I can build a trivial extension with mingw which can be loaded by
python 2.6, by embedding manifest with gcc + windres (that is by using
a toolchain 100 % mingw-based, without using any MS tool like mt.exe).

That shouldn't be necessary - extension modules should be able to find
the CRT without an embedded manifest, assuming the process has already
loaded it.

- numpy, at the configuration stage, builds some small code snippets
and run them: to run, they have to embed manifests as well. I think
this should be somewhat supported by distutils ?

I don't think so - see above.

- which manifest file to use: for now, I am using a manifest file
copied from the python binary itself (using strings on python.exe). It
works, but I guess this means that the extensions are specific to
this exact binary: python 2.6 reports the version 9.0.21022.8, the MS
runtime in redist directory of my copy of visual studio 2008 express
reports 9.0.30729.1. If python 2.6.1 is built with another version, am
I right to assume it will break (because it would use two different
runtimes) ? Would it makes sense to make the exact version of the
runtime available to distutils so that we can generate manifest on the
fly for mingw ?

Just don't embed any manifest - see above.

Regards,
Martin