[Numpy-discussion] NumPy and Python 2.6 on Windows
Sun Dec 28 00:33:02 CST 2008
David Cournapeau wrote:
> Lenard Lindstrom wrote:
>> Sorry for the confusion. I meant that I don't like patching SDL and
>> such. I build these in msys using the "configure; make install"
>> incantation, so can't easily use magic like manifest files.
> I don't know about SDL :) numpy needs manifests at the configuration
> stage, because it build code snippet which it needs to run, and this
> requires manifest AFAIK, if you link against msvcr90.dll. I did not want
> to link with another dll at the configuration stage, because this could
> lead to subtle issues.
Yes, it is best to have configuration programs link to msvcr90.dll when
possible. Pygame configuration is relatively straight forward. No test
programs are used. But all the dependencies, such as SDL, are built with
Msys, and the Unix configuration shell scripts are used when possible.
These scripts do create small test programs. It would be possible
provide manifest files in this case, but only after determining the
names and locations of all the test programs generated. For now it is
simpler to just use a less fussy C runtime during configuration, then
link in msvcr90 later.
>> Instead I
>> link the DLLs against msvcr71.dll, making sure there are also static
>> libraries, then create the msvcr90.dll linked DLL's from the static
>> libraries. This trick can also be used with the NumPy dependencies Blas
>> and fftw. Actually it is easier, since they are statically linked into
> Note that numpy does not depend on fftw.
> My solution to this was to generate the manifest file, which was
> relatively easy to do since we control our build process in python (look
> at numpy/distutils/mingw32compiler.py). To run a program 'locally' (one
> which is not installed), having the manifest in the same directory as
> the .exe is enough, so we only need to generate it. The main difficulty
> is to make sure you are using the same version of the dll as python:
> this feature has been integrated in python 2.6.1. For 2.6.0, I just
> assume it is the same as the official python binary.
A manifest file will work as long as the public key doesn't change. Or
is the key provided by the developer rather than Microsoft's build tools?
>> Yes, I've had my run in with manifest files. I avoid them by linking
>> test programs against msvcrt or msvcr71 instead. A manifest is not
>> needed for a DLL, luckily, as it uses the DLL libraries loaded by its
>> host program.
> Yes, that's my understanding too. Since this is of course undocumented,
> we can only guess.
Well, this is what I've found for Python and Pygame extension modules
anyway. And it makes a certain amount of sense if manifests exist to
prevent library conflicts. A dynamic library and main program using
different C runtime instances would be a problem.
>> And I've had no luck using msvcr90.dll outside an SxS
>> assembly. It needs a manifest file wherever it is, and I have had yet to
>> writing a working manifest for a private assembly. So the Python
>> developers' solution of copying msvcr90.dll into the Python directory is
>> of no help.
> This may be of some interest for you:
> that's a summary of my own findings about manifest using only open
> source tools. All the necessary code, including the manifest template is
> in the mingw32compiler.py file:
Ok, you have given me some more things to consider. Thanks for the
discussion. I will keep you suggestions in mind. Just to clear up any
confusion pygame.org is not intending to build and distribute NumPy with
Pygame. NumPy was required to run the full Pygame test suite under
Python 2.6. My custom NumPy build will disappear once scipy.org releases
its Python 2.6 build.
More information about the Numpy-discussion