Using FFTW3 static lib with JUCE_dsp

Good afternoon,

I am attempting to use someone else’s JUCE based open-source binaural rendering project in my work, and they noted that they require the FFTW3 lib, which as I understand it in their project is used by the JUCE_DSP convolution and fft objects.

So I have gone and accessed the FFTW3 pre-compiled-for-windows files that are then ‘libified’ using the lib.exe tool. I have added the lib dependency and the appropriate flags in the freshly added VS2019 jucer exporter, and on build I get as far as linking, where I appear to get some unresolved symbols. Clearly the lib is accessed by the linker, but the symbols can’t be found.

What is interesting to me is that, if I look in the fftw3.h header file, indeed I cannot see symbols with the exact naming convention used in the juce_FFT header.
Please, could someone tell me if I am being a numpty and there is an obvious step I have missed?
Thank you

Ah, i’m sure this won’t help.
And from the FFTW3 lib readme_windows:

This is meant to be the “64bit” library according to the FFTW website

Just looked at the project you linked, and it looks like @danielrudrich who’s around here on the forum is one of the contributors – maybe he can help.

Two thoughts, the macro says JUCE_DSP_USE_STATIC_FFTW and you link to a source where you can download DLLs – these are obviously no static libraries, even if wrapped into a .lib. Maybe you want to try compiling it yourself into a static library from source, using the Microsoft Visual C++ compiler instead of MinGW. I guess this should work, but I only compiled FFTW on macOS and Linux myself and it’s been a few years since I did so for the last time.

Anyway, the code you linked above looks like an excerpt of the juce::dsp::fft internals, which is built in a way that you can optionally use fftw as the FFT engine used, but you don’t necessarily need to, there is also a fallback implementation, that will always work. So in case the project only uses the JUCE FFT classes and does not call fftw functions directly, I don’t see any reason why it won’t work without fftw – you should definitely be able to disable the code above by not setting JUCE_DSP_USE_STATIC_FFTW.

Thanks for your help!
I emailed @danielrudrich who promptly and kindly sent me a zip of the lib, and now I have successfully linked and run the project(s) with the statically linked FFTW3 flag enabled.

However, on the FFTW website they give the instructions (for windows) to download that pre-compiled library and execute the ‘lib’ wrapping.
I naively thought that these instructions are what I needed, but yes it appears I should compile the lib on windows, which I guess I will do for any further project I make that use it.
I guess the lesson here is not to rely on compiled libs that might be a bit suspicious such as these, as the authors (of FFTW) also not ‘we don’t develop on windows’.


I just ran into the same issue… since then have you been able to come up with a usable cmake/sln to build the latest FFTW on Windows? I did stumble on this repo providing this kind of solution, but it does not seem to work for me. Can’t get the solution to build properly and the prebuilt binary does not seem valid either, not exactly sure why.


Edit: looks like the repo’s solution is for a specific version of FFTW, which might not fit the sources I’ve downloaded from the official website… I did tweak it a little to get it to build, but when I try to link it with JUCE, it looks like I have some internal symbols issues in FFTW.

I gotta be honest, I don’t really remember as this was some time ago.
I THINK I got it to work with a load of swearing, but I can’t remember how and if so for the life of me.
I was doing this specifically to build IEM plugins, and in later similar projects I just ended up rolling my own complete variants of their projects but for my own purposes (with attribution, non-commercial yada yada).
If I were trying to use an FFT acceleration lib today, I would probably go with rolling your own wrapper around the intel IPP library. I assume there is an alternative for AMD and ARM that you could also wrap. Another thing worth looking at are the the WDL libraries FFT which I have in some code I referenced in another project.

Strangely, I just had the smoothest experience building the latest FFTW… if you get the latest sources at FFTW Download Page, you’ll see a CMakeLists.txt file in the folder. I took a chance with the CMake-GUI and it generated/built everything and it linked with my JUCE project without any complaint.

I feel so light now…

I built a static FFTW3 on windows using CMake and the Visual Studio 2019 build target, but I noticed only the AVX2 was detected and used in the build, and not any SSE or SSE2. What cmake setup output did you get on your system?

Exactly the same actually! In terms of performances this did not come up as an issue for me. I feel like this is specific to the system running, but it’s a bit out of my league so I could not really tell why or how to enable additional stuff in that regards.

I think that because most modern machines after 2015 or so have AVX2 support, it works out OK, but there is a lot of hardware out there that would only have SSE2 and I imagine an FFTW built without those optimizations would not be a good thing…

did you use the static link or dynamic link?