Lenard Lindstrom wrote:
> David Cournapeau wrote:
>> Hi Lenard,
>>
>>
>> On Sun, Dec 28, 2008 at 5:05 AM, Lenard Lindstrom <le...@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
_______________________________________________
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
