[Numpy-discussion] NumPy and Python 2.6 on Windows

David Cournapeau david@ar.media.kyoto-u.ac...
Sat Dec 27 20:58:55 CST 2008


Lenard Lindstrom wrote:
> David Cournapeau wrote:
>> Hi Lenard,
>>
>>
>> On Sun, Dec 28, 2008 at 5:05 AM, Lenard Lindstrom <len-l@telus.net> wrote:
>>   
>>> Hi everyone,
>>>
>>> I build the Pygame dependencies for Windows. With the next Pygame
>>> release, 1.9.0, we would like to include Python 2.6 support. As you
>>> already know, Pygame has NumPy bindings. Though NumPy is not required,
>>> it is a useful addition. I understand NumPy is built with MinGW on
>>> Windows, which I use to with Pygame and its dependencies. I know the
>>> problems linking against msvcr90.dll. I am willing to offer what advice
>>> I can to get NumPy up and running for Python 2.6.
>>>     
>> Thanks. I think I have covered most problems concerning python 2.6 and
>> windows in the trunk (upcoming 1.3):
>>
>>  - linking against msvcr90.dll
>>  - generating manifest for running code snippets (with mingw)
>>  - fix some bugs with python 2.6 msvc support (in particular
>> http://bugs.python.org/issue4702)
>>
>> You are welcome to test the trunk to see if that fixes everything. I
>> don't think everything can be fixed for 1.2.2, because the changes are
>> not all trivial (much revamp C99 math support, in particular).
>>
>> Unfortunately, I have been working on some formatting issues which
>> were more difficult than previously thought, and it was time to go to
>> sleep before I actually fixed the problem, so the trunk may be broken
>> ATM. I will fix this now,
>>
>>   
> It looks like you have a handle on the problem. How did you get around 
> the problems with the incomplete libmsvcr90.a import library? I have 
> custom import libraries which you can use if needed.

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. You can look at
revisions r6080, r6076, r6074, r6073, r6072,r6070,r6069,r6029,r6028, the
final patch is as follow:

diff --git a/numpy/random/mtrand/randomkit.c
b/numpy/random/mtrand/randomkit.c
index 56f52c0..0fbc40d 100644
--- a/numpy/random/mtrand/randomkit.c
+++ b/numpy/random/mtrand/randomkit.c
@@ -64,18 +64,33 @@
 
 /* static char const rcsid[] =
   "@(#) $Jeannot: randomkit.c,v 1.28 2005/07/21 22:14:09 js Exp $"; */
-
 #include <stddef.h>
 #include <stdio.h>
 #include <stdlib.h>
 #include <errno.h>
-#include <time.h>
 #include <limits.h>
 #include <math.h>
 
 #ifdef _WIN32
 /* Windows */
+/* XXX: we have to use this ugly defined(__GNUC__) because it is not
easy to
+ * detect the compiler used in distutils itself */
+#if (defined(__GNUC__) && defined(NPY_NEEDS_MINGW_TIME_WORKAROUND))
+/* FIXME: ideally, we should set this to the real version of MSVCRT. We
need
+ * something higher than 0x601 to enable _ftime64 and co */
+#define __MSVCRT_VERSION__ 0x0700
+#include <time.h>
 #include <sys/timeb.h>
+/* mingw msvcr lib import wrongly export _ftime, which does not exist
in the
+ * actual msvc runtime for version >= 8; we make it an alias to
_ftime64, which
+ * is available in those versions of the runtime
+ */
+#define _FTIME(x) _ftime64((x))
+#else
+#include <time.h>
+#include <sys/timeb.h>
+#define _FTIME(x) _ftime((x))
+#endif
 #ifndef RK_NO_WINCRYPT
 /* Windows crypto */
 #ifndef _WIN32_WINNT
@@ -86,6 +101,7 @@
 #endif
 #else
 /* Unix */
+#include <time.h>
 #include <sys/time.h>
 #include <unistd.h>
 #endif
@@ -167,7 +183,7 @@ rk_error rk_randomseed(rk_state *state)
     rk_seed(rk_hash(getpid()) ^ rk_hash(tv.tv_sec) ^ rk_hash(tv.tv_usec)
         ^ rk_hash(clock()), state);
 #else
-    _ftime(&tv);
+    _FTIME(&tv);
     rk_seed(rk_hash(tv.time) ^ rk_hash(tv.millitm) ^ rk_hash(clock()),
state);
 #endif
 
diff --git a/numpy/random/setup.py b/numpy/random/setup.py
index e7955db..dde3119 100644
--- a/numpy/random/setup.py
+++ b/numpy/random/setup.py
@@ -1,13 +1,19 @@
-from os.path import join, split
+from os.path import join, split, dirname
+import os
 import sys
+from distutils.dep_util import newer
+from distutils.msvccompiler import get_build_version as
get_msvc_build_version
 
-def msvc_version():
-    """Return the msvc version used to build the running python, None
if not
-    built with MSVC."""
-    msc_pos = sys.version.find('MSC v.')
-    if msc_pos != -1:
-        return sys.version[msc_pos+6:msc_pos+10]
-    return None
+def needs_mingw_ftime_workaround():
+    # We need the mingw workaround for _ftime if the msvc runtime
version is
+    # 7.1 or above and we build with mingw ...
+    # ... but we can't easily detect compiler version outside distutils
command
+    # context, so we will need to detect in randomkit whether we build
with gcc
+    msver = get_msvc_build_version()
+    if msver and msver >= 8:
+        return True
+
+    return False
 
 def configuration(parent_package='',top_path=None):
     from numpy.distutils.misc_util import Configuration, get_mathlibs
@@ -22,6 +28,10 @@ def configuration(parent_package='',top_path=None):
         ext.libraries.extend(libs)
         return None
 
+    defs = []
+    if needs_mingw_ftime_workaround():
+        defs.append(("NPY_NEEDS_MINGW_TIME_WORKAROUND", None))
+
     libs = []
     # Configure mtrand
     config.add_extension('mtrand',
@@ -32,7 +42,8 @@ def configuration(parent_package='',top_path=None):
                          depends = [join('mtrand','*.h'),
                                     join('mtrand','*.pyx'),
                                     join('mtrand','*.pxi'),
-                                    ]
+                                    ],
+                         define_macros = defs,
                         )
 
     config.add_data_files(('.', join('mtrand', 'randomkit.h')))


David


More information about the Numpy-discussion mailing list