[Numpy-discussion] toward python 2.6: mtrand, gettimeofday and mingw
Fri Nov 14 01:40:20 CST 2008
On Fri, Nov 14, 2008 at 01:14, David Cournapeau
> Since I think it would be nice for numpy 1.3 to support python 2.6,
> I took a further look at it on windows. AFAICS, there is only one
> problem remaining, when building with mingw. The error is exactly as in
> the following bug report:
> I am not sure I understand exactly the problem in numpy case: the
> failure appears in mtrand, because of the function gettimeofday. I can't
> find gettimeofday on MSDN (google only returns link to a win32
> replacement for gettimeofday), so I don't understand why it works fine
> when compiling with VS 2008.
> Since the problem is specific to python 2.6, which depends on the MS C
> runtime 9.0 (the one with Visual Studio 2008), I *guess* that mingw has
> an implementation of gettimeofday internally which depend on those time
> functions, and since its MS runtime 9.0 wrapper for it (libmsvcr90.a)
> wrongly defines some time-related functions which are not exported by
> the MS runtime, it fails.
> Anyway, one solution would be to implement our own gettimeofday from MS
> specific functions (such code is available on the internet, and is only
> a few lines), or use directly MS specific functions. My understanding is
> that since this is used for the random seed, the exact time returned by
> the function does not matter much, but it would mean that the seed would
> be different from what it used to be, and some people complained
> recently about similar issues. Of course, the right fix is for mingw to
> fix its def files for msvc runtimes, but given that last mingw release
> was a long time ago, I don't think we would be able to build numpy 1.3
> with it without workaround.
Feel free to change it to whatever works. The point of that seeding
mode is that it *is* different each time you call it.
"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
-- Umberto Eco
More information about the Numpy-discussion