[Numpy-discussion] need help building a numpy extension that uses fftpack on windows

[martin smith]

On 6/3/2011 5:15 AM, Ralf Gommers wrote:
> 
> 
> On Thu, Jun 2, 2011 at 9:33 PM, Robert Kern <robert.kern at gmail.com
> <mailto:robert.kern at gmail.com>> wrote:
> 
>     On Thu, Jun 2, 2011 at 14:07, Ralf Gommers
>     <ralf.gommers at googlemail.com <mailto:ralf.gommers at googlemail.com>>
>     wrote:
>     >
>     > On Wed, Jun 1, 2011 at 5:45 PM, martin smith <gmane at blindgoat.org
>     <mailto:gmane at blindgoat.org>> wrote:
>     >>
>     >> I have a bit of code that performs multi-taper power spectra
>     using numpy
>     >> and a C extension module.  The C portion consists of an interface
>     file
>     >> and a python-unaware computational file.  The latter invokes fftpack.
>     >>
>     >> The straightforward setup.py appended below works fine on Linux.  On
>     >> Windows using MinGW it's not so good. I first created a libpython27.a
>     >> file following instructions on the web.  The C code now compiles but
>     >> fails to link since there is no fftpack_lite.so on Windows.  I can't
>     >> find an fftpack_lite.dll (or even the source for fftpack_lite)
>     and don't
>     >> know where to turn.
>     >
>     > Python dll's on Windows have a .pyd extension, there should be a
>     > fftpack_lite.pyd file. But you should be able to just leave off the
>     > extension, so it does the right thing on any platform.
>     >
>     > Also, the way you specified library_dirs doesn't work if numpy is
>     not in
>     > site-packages, better to use something like:
>     >      library_dirs = [os.path.join(numpy.__path__[0], 'fft')]
> 
>     That said, there is no good cross-platform way to link against other
>     Python extension modules. Please do not try. You will have to include
>     a copy of the FFTPACK code in your own extension module.
> 
> Coming back to #608, that means there is no chance that  the C version
> will land in scipy, correct? We're not going to ship two copies of
> FFTPACK. So the answer should be "rewrite in Python, if that's too slow
> use Cython".
> 
> Ralf
>  

Thank you both for your prompt response and suggestions.  I've modified
the setup.py file as Ralf suggested and concocted a version of the code
(summarized below) that doesn't try to link to existing modules.

The formal problem with a python rewrite is that there is some
functionality in the package (the adaptive spectrum estimate) that
requires solving an iterative non-linear equation at each frequency.  A
practical problem is that the odds of my rewriting the core code in
python in the near future are not good.

I've made an include file for the core code from a version of fftpack.c
by stripping out the unused functions and making the survivors static.
Using this means, of course, that you'd be partly duplicating fftpack
from a binary bloat point of view but it leads to a plausible solution,
at least.

I'm currently having (new) problems compiling on win7 64-bits
(msvcr90.dll for 64bits is missing and I haven't had any luck googling
it down yet) as well as on winxp 32-bits (my installation of mingw is
confused and can't find all of its parts).  I'm planning to stick with
it a while longer and see if I can get past these bumps.  If I succeed
I'll reraise the possibility of getting it into scipy.

- martin