Okay, let’s start step by step
When adding external libraries to your project, there are a few generally different approaches.
You can compile the libraries code along with your project code. This means that you need access to the headers and the implementation (.c/.cpp files) and compile the source files the same way you compile your projects files. In many cases, libraries need some specific build settings that might clash with your projects build settings or they simply consist of a lot of files, so it’s better to compile them separately or directly obtain a precompiled version of the library and its corresponding headers.
While the code compiled along with your project will always become a part of your binary, this is not always the case for pre compiled libraries.
A static linked library will become a part of your binary. Those libraries have a .a file extension on macOS/Linux and a .lib file extension on Windows. This means, after linking to them at compile time, you don’t need them anymore.
A dynamically linked library won’t become a part of your binary. Those libraries have a .dylib file extension on macOS, .so on Linux and .dll on Windows. You need them during compile time and during runtime. So, if they were available at a known location during compile time, the linker will be able to find them in this step. But the linker is not only used while compiling, it will kick in again every time you try to open the application that uses a dynamic library, and will look where to find that dynamic library since the executable parts of your library are not present in your application or plugins binary. If this fails, you usually get some hard crashes instead of more or less understandable linker errors you see if the linker does not find some function at compile time.
All operating systems have their own convention regarding where the runtime linker will look for libraries at runtime. And you have to make sure that your plugin installer will place your dynamic library dependencies in a suitable location on your system in order to make the plugin run. Since this can be a bit challenging to get right, most plugin developers chose statically linked libraries.
I hope this helped you understand the basics a bit better. So now, do you link your Windows build against a .lib (static) or a .dll (dynamic) version of FFTW? You must have chosen at least one of them in order to complete compilation successfully.