Hello all,
I have scowered the internet searching for binaries of FFTW that use an MS-MPI implementation for windows 7 but have been unable to find one. This has caused me to try and compile FFTW 3.3.2 using the PGI workstation (x64 v12.5) bash. Unfortunetly this is not going well.
I start by setting my environment variables as such:
MPILIBS=/c/.../.../msmpi.lib (because in configure it can't seem to see it which I think has to do with the root of the problem)
MPICC=pgcc
MPIEXEC=mpiexec (from MS-MPI HPC PAC 2008 SDK with SP2)
NM=pgnm
PGI_OBJSUFFIX=o
Then, in the configure file where it says “#include <mpi.h>” I write instead “#include “/c/…/…/mpi.h””
Then I run the configure line as suggested at FFTW only with mpi and without threads (tried with threads; same error):
PGI$ ./configure F77=pgfortran FC=pgfortran --prefix=/c/buildFFTW --enable-mpi --enable-shared=yes --with-our-malloc16 --with-windows-f77-mangling --disable-static --enable-sse2
The configure file does not die but fails in places I think it shouldn’t:
...
checking command to parse pgnm output from pgcc object... failed
...
checking size of MPI_Fint... 0
configure: WARNING: sizeof(MPI_Fint) test failed
...
checking for dummy main to link with Fortran 77 libraries... unknown
configure: WARNING: *** Couldn't figure out how to link C and Fortran; using default Fortran wrappers.
...
then when I run the resulting make it succefully compiles and links a lot of things but then fails to link static libraries giving out:
pgcc -Masmkeyword -DHAVE_CONFIG_H -I. -I.. -fast -c verify-lib.c
source='verify-r2r.c' object='verify-r2r.o' libtool=no \
DEPDIR=.deps depmode=none /bin/sh ../depcomp \
pgcc -Masmkeyword -DHAVE_CONFIG_H -I. -I.. -fast -c verify-r2r.c
source='verify-rdft2.c' object='verify-rdft2.o' libtool=no \
DEPDIR=.deps depmode=none /bin/sh ../depcomp \
pgcc -Masmkeyword -DHAVE_CONFIG_H -I. -I.. -fast -c verify-rdft2.c
source='verify.c' object='verify.o' libtool=no \
DEPDIR=.deps depmode=none /bin/sh ../depcomp \
pgcc -Masmkeyword -DHAVE_CONFIG_H -I. -I.. -fast -c verify.c
source='zero.c' object='zero.o' libtool=no \
DEPDIR=.deps depmode=none /bin/sh ../depcomp \
pgcc -Masmkeyword -DHAVE_CONFIG_H -I. -I.. -fast -c zero.c
source='my-getopt.c' object='my-getopt.o' libtool=no \
DEPDIR=.deps depmode=none /bin/sh ../depcomp \
pgcc -Masmkeyword -DHAVE_CONFIG_H -I. -I.. -fast -c my-getopt.c
rm -f libbench2.a
pgar cru libbench2.a after-ccopy-from.o after-ccopy-to.o after-hccopy-from.o aft
er-hccopy-to.o after-rcopy-from.o after-rcopy-to.o allocate.o aset.o bench-cost-
postprocess.o bench-exit.o bench-main.o can-do.o caset.o dotens2.o info.o main.o
mflops.o mp.o ovtpvt.o pow2.o problem.o report.o speed.o tensor.o timer.o usero
pt.o util.o verify-dft.o verify-lib.o verify-r2r.o verify-rdft2.o verify.o zero.
o my-getopt.o
ranlib libbench2.a
make[2]: Leaving directory `/c/3build/fftw-3.3.2/libbench2'
Making all in .
make[2]: Entering directory `/c/3build/fftw-3.3.2'
/bin/sh ./libtool --tag=CC --mode=link pgcc -Masmkeyword -fast -no-undefined
-version-info 6:2:3 -o libfftw3.la -rpath /c/buildFFTW/lib kernel/libkernel.la
dft/libdft.la dft/scalar/libdft_scalar.la dft/scalar/codelets/libdft_scalar_cod
elets.la rdft/librdft.la rdft/scalar/librdft_scalar.la rdft/scalar/r2cf/librdft_
scalar_r2cf.la rdft/scalar/r2cb/librdft_scalar_r2cb.la rdft/scalar/r2r/librdft_s
calar_r2r.la reodft/libreodft.la api/libapi.la simd-support/libsimd_support.la s
imd-support/libsimd_sse2_nonportable.la dft/simd/sse2/libdft_sse2_codelets.la rd
ft/simd/sse2/librdft_sse2_codelets.la
libtool: link: (cd .libs/libfftw3.lax/libkernel.lib && pgar x "/c/3build/fftw-3.
3.2/kernel/.libs/libkernel.lib")
libtool: link: object name conflicts in archive: .libs/libfftw3.lax/libkernel.li
b//c/3build/fftw-3.3.2/kernel/.libs/libkernel.lib
make[2]: *** [libfftw3.la] Error 1
make[2]: Leaving directory `/c/3build/fftw-3.3.2'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/c/3build/fftw-3.3.2'
make: *** [all] Error 2
Is there some flag I need to use/not use to link to an already existing .lib? After all this is said and done I hope to be able to use Visual studios to compile MyPROG.exe and link to the FFTW and MS-MPI libraries and run my program in windows. I had tried building OpenMPI and MPICH2 but to link with instead of MS-MPI but had slightly similar problems. If there is a different FFT (hopefully about as good and free) with MPI-2 API calls designed to work with MS-MPI I would also be interested in that should this build not be possible.
Thanks if you can help!
-Gabe
Hi Gabe,
I’ll go grab FFTW and see if I can figure it out. I’m not hopefully however since it’s my understanding that libtool is MinGW and doesn’t work with native Windows. According to FFTW website (FFTW Installation on Windows) the general Windows libraries are MinGW so won’t work outside of a MinGW environment. Long ago (5.x) the PGI compilers we’re MinGW based but we went native in order to integrate into Visual Studio and be interoperable with Microsoft.
The best bet may be to follow the Visual Studio build instructions. I’ve never tried it, but will give it a go. Worst case, you’ll need to by-pass the build scripts and build it by hand.
Mat,
Thank you for taking the time to look into this issue, I still have not been able to deal with this problem.
I have however found a likley option in the event FFTW is unusable. aperently the MKL library from the dreaded intel can handel FFTW style function calls from versions 2 and 3 Accelerate Fast Math with Intel® oneAPI Math Kernel Library
Personally I’d rather not end up at their mercy but it might be my only option if an FFTW windows build is not possible.
-Gabe
Hi Gayle,
Just an update in case I don’t finish before heading out. I was able to get farther than you by also using the environment variable “AR=pgar”. Also, it doesn’t look like PGI_OBJSUFFIX=o is needed. To simplify things, I did not use MPI or any of your configure options except --prefix.
Now I’m getting undefined symbol errors the “fftw_mksolver” symbol and hunting down where this symbol comes from and why it’s not being included in the library.
Note that MKL is great library so would be a fine way to go. However, I’ve only used it on Linux and they note on their web page that “PGI Fortran support on Windows is limited”. Though, I’m not sure what they mean by that.
After tabling this issue and coming back to it, I’ve acquired an MKL trial license. To use it as a replacement for FFTW you need to create two wrapper libraries, namely fftw2x_cdft_DOUBLE.lib and fftw2xf_double_msvs.lib which are created in \mkl\lib\intel64.
when creating these libraries I used the intel makefiles and visual studios cl.exe with the following command line
nmake libintel64 mpi=msmpi fname=a_name mpidir="C:\Program Files\Microsoft HPC Pack 2008 SDK" precision=MKL_DOUBLE compiler=msvs
everything compiles and the libraries are created. In visual Fortran I select include MKL in the preferances window as well as including the linker preferances the MKL library’s lib directory (includes a dummy libiomp5mt.lib) and the two .lib files in the additional dependencies list. and I get link errors of the sort
error LNK2019: unresolved external symbol fftw_f77_create_plan_ referenced in function
error LNK2019: unresolved external symbol fftwnd_f77_mpi_ referenced in function etc....
I checked the intel forums but didn’t find any help there. Any ideas what I’ve left out?
Hi Gabe,
Given just this information, my guess is that these are C wrapper routines and the problem has to do with how the symbol names are being decorated. Try searching the source for the definitions of these routines to see how they are declared. CL is a C++ compiler, therefore if the names don’t have an Extern “C” around them, they may be getting name mangled. Also, C doesn’t append an underscore to symbol names, so you many need to add one.
You can also try using the “pgnm” utilitiy on your libraries and search from these symbol names. It will tell us if they exist and how they are decorated.
i.e. pgnm *.lib | grep “fftw_f77_create_plan”
Hope this helps,
Mat
Okay, first these are the exact link errors:
Compiling Project ...
Linking...
aim_mod29.obj : error LNK2019: unresolved external symbol fftw_f77_create_plan_ referenced in function aim_compute_inv_gaussian_
aim_mod29.obj : error LNK2019: unresolved external symbol fftw_f77_one_ referenced in function aim_compute_inv_gaussian_
aim_mod29.obj : error LNK2019: unresolved external symbol fftw_f77_destroy_plan_ referenced in function aim_compute_inv_gaussian_
aim_nfield_corr9.obj : error LNK2001: unresolved external symbol fftw_f77_destroy_plan_
aim_mod29.obj : error LNK2019: unresolved external symbol fftwnd_f77_mpi_ referenced in function aim_center_find_
solver_v20timed.obj : error LNK2001: unresolved external symbol fftwnd_f77_mpi_
aim_mod29.obj : error LNK2019: unresolved external symbol fftwnd_f77_mpi_create_plan_ referenced in function aim_pack_propagat_
aim_mod29.obj : error LNK2019: unresolved external symbol fftwnd_f77_mpi_local_sizes_ referenced in function aim_pack_propagat_
aim_nfield_corr9.obj : error LNK2019: unresolved external symbol fftwnd_f77_create_plan_ referenced in function aim_correct_nfield_nfield_correct_
aim_nfield_corr9.obj : error LNK2019: unresolved external symbol fftwnd_f77_one_ referenced in function aim_correct_nfield_nfield_correct_
C:\tfs_root\EM.CUBE\AIM_Windows\mom3D\AIMwin64\AIMwin64\x64\Debug\exe.exe : fatal error LNK1120: 8 unresolved externals
exe build failed.
so I’ve done as you suggested and the type of output I get is below.
$ pgnm *.lib | grep "fftwnd_f77_mpi"
00000256 T fftw2x_cdft_DOUBLE.lib;obj\rnd_local_sizes.obj;_rfftwnd_f77_mpi_local_sizes
00000432 T fftw2x_cdft_DOUBLE.lib;obj\rnd_fftw.obj;_rfftwnd_f77_mpi
00000080 T fftw2x_cdft_DOUBLE.lib;obj\rnd_destroy_plan.obj;_rfftwnd_f77_mpi_destroy_plan
00001264 T fftw2x_cdft_DOUBLE.lib;obj\rnd_create_plan.obj;_rfftwnd_f77_mpi_create_plan
00000256 T fftw2x_cdft_DOUBLE.lib;obj\nd_local_sizes.obj;_fftwnd_f77_mpi_local_sizes
00000336 T fftw2x_cdft_DOUBLE.lib;obj\nd_fftw.obj;_fftwnd_f77_mpi
00000080 T fftw2x_cdft_DOUBLE.lib;obj\nd_destroy_plan.obj;_fftwnd_f77_mpi_destroy_plan
00001040 T fftw2x_cdft_DOUBLE.lib;obj\nd_create_plan.obj;_fftwnd_f77_mpi_create_plan
$ pgnm *.lib | grep "fftw_f77_create_plan"
fftw2xf_double_msvs.lib[obj_double_msvs\rfftw_f77_create_plan.obj];
00000000 t fftw2xf_double_msvs.lib;obj_double_msvs\rfftw_f77_create_plan.obj;.text
00000000 T fftw2xf_double_msvs.lib;obj_double_msvs\rfftw_f77_create_plan.obj;_RFFTW_F77_CREATE_PLAN
fftw2xf_double_msvs.lib[obj_double_msvs\fftw_f77_create_plan.obj];
00000000 t fftw2xf_double_msvs.lib;obj_double_msvs\fftw_f77_create_plan.obj;.text
00000000 T fftw2xf_double_msvs.lib;obj_double_msvs\fftw_f77_create_plan.obj;_FFTW_F77_CREATE_PLAN
So as far as I can tell they are in these libraries. On the MKL website it talks about making sure to run your examples with their include files fftw_f77.i, fftw.h , fftw_mpi.h, rfftw.h, and rfftw_mpi.h. The only one I include is the fftw_f77.i file but it is just a bunch of FFTW constant definitions that I already define in my project. I don’t do anything with the others since they are C header files. Should I be using these somehow?
Hi Gabe,
00000336 T fftw2x_cdft_DOUBLE.lib;obj\nd_fftw.obj;_fftwnd_f77_mpi
It looks like this library is using the “C” calling convention rather than the default Win64. Try adding “-Miface=cref”. Granted, you may have issues linking with other libraries if a “C” interface is not available.
fftw2xf_double_msvs.lib;obj_double_msvs\fftw_f77_create_plan.obj;_FFTW_F77_CREATE_PLAN
This one looks to also be using the “C” calling convention, but is also preserving case sensitivity. Try compiling with “-Miface=cref -Mupcase” and then change your call to this routine to all upper case letters. Note that “-Mupcase” is a bit tricky since now all out external references must now be upper case.