[Numpy-discussion] NumPy and Python 2.6 on Windows
Sat Dec 27 22:34:11 CST 2008
David Cournapeau wrote:
> Lenard Lindstrom wrote:
>> David Cournapeau wrote:
>>> Do you mean on xp 32 bits or 64 bits ? For the later, I have yet to
>>> submit patchs to the mingw-w64 project - the whole libmsvcr90.a is
>>> missing, actually. For 32 bits, I simply got around it by changing the
>>> missing functions in numpy itself - if we are talking about the same
>>> thing, that is missing time functions for random.
>> Yes, the _ftime function, which is an inlined function in VC 2008 that
>> calls _ftime64. I have to build a lot of dependencies for Pygame so I
>> want to avoid patching code when possible.
> I understand you don't want to patch the sources. The above fix is in
> the trunk, though - and I don't feel like backporting those fixes in the
> 1.2.x branch, because it would be a lot of work.
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. 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
>> Instead I have a custom
>> libmsvcr90.a that has stub functions for the various time functions. It
>> lets me create static libraries that link to both msvcr71.dll and
>> msvcr90.dll. No manifest files required. And no patches to MinGW.
> Manifests are needed for any executable linking against msvcr90.dll,
> whether you build with mingw or VS: this is required by windows itself
> to be able to load msvcr90.dll at all (the dreadful Side by Side
> assembly stuff). This is a totally independent issue of the _ftime
> thing, and AFAIK, there is no way around it - except installing
> msvcrt90.dll in system32 yourself, which is obviously a very bad idea.
> Patching mingw is necessary for 64 bits support, since their headers are
> missing some math functions - no patch is needed for 32 bits.
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. 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.
More information about the Numpy-discussion