[SciPy-dev] issues with distributing Numeric separately on windows

[eric]

Group,

When upgrading to Python2.2 I re-discovered a windows specific issue that Travis
O. and I fought with before releasing SciPy-0.1.  It has to do with Numeric and
fastumath.  These guys work very closely together.

On windows, the pre-compiled binaries available from source-forge are compiled
with MSVC compiler.  SciPy, and hence fastumath, is compiled with gcc.  This
works fine except for calls from Numeric C extensions into the C code of
fastumath that return complex numbers.  There is a binary incompatibility
between MSVC and gcc in their structure layout that results in segmentation
faults on complex number operations.  So:

    >>> from scipy_base import *
    >>> array(1+1j)/1.

will cause a seg fault if you use the standard Numeric module with SciPy.

Some people balked when SciPy was distributed with Numeric last time.  We've
endeavored to separate things out this time so that that wasn't necessary.
However, this is pretty much a show stopper on windows -- and was major reason
we bundled them last time.  I think we'll have to distribute a gcc compiled
version of Numeric with SciPy on windows.  This will get installed over (will
clobber) your old installation of Numeric in the process.  It does not affect
Numeric's other than making it version 21.0. By this I mean, the gcc and MSVC
versions will work identically and work with all your extension modules.

If anyone has run into the binary incompatibility issue before and discovered a
solution, I'd love to here it.  I found the --native-struct flag for mingw, but
it didn't seem to help.  One other solution is to get SciPy working with MSVC.
I think it might be possible (though there are some big issues), but it isn't a
high priority.

So, let me know if you have a solution,

eric

--
Eric Jones <eric at enthought.com>
Enthought, Inc. [www.enthought.com and www.scipy.org]
(512) 536-1057