Always linked against fftw3f even when single precision is not requested
dev-zero opened this issue · 2 comments
The consequence of the current logic
SpFFT/cmake/modules/FindFFTW.cmake
Lines 97 to 102 in 473cf75
is that libspfft.so
is always linked against libfftw3f.so
if found even when single precision is not requested.
Furthermore I see libfftw3_threads
to be linked despite spfft
not calling fftw with threads (just a quick glance, I may be wrong):
$ readelf -d /project/d110/timuel/spack/opt/spack/cray-sles15-zen2/gcc-10.2.0/spfft-1.0.3-meadkxxxregbcgl43lrhm4tb26vrs6o3/lib64/libspfft.so.1
Dynamic section at offset 0x38c18 contains 41 entries:
Tag Type Name/Value
0x0000000000000001 (NEEDED) Shared library: [libfftw3f_omp.so.mpi31.3]
0x0000000000000001 (NEEDED) Shared library: [libfftw3_omp.so.mpi31.3]
0x0000000000000001 (NEEDED) Shared library: [libgomp.so.1]
0x0000000000000001 (NEEDED) Shared library: [libfftw3.so.mpi31.3]
0x0000000000000001 (NEEDED) Shared library: [libfftw3f.so.mpi31.3]
0x0000000000000001 (NEEDED) Shared library: [libfftw3f_mpi.so.mpi31.3]
0x0000000000000001 (NEEDED) Shared library: [libfftw3f_threads.so.mpi31.3]
0x0000000000000001 (NEEDED) Shared library: [libfftw3_mpi.so.mpi31.3]
0x0000000000000001 (NEEDED) Shared library: [libfftw3_threads.so.mpi31.3]
0x0000000000000001 (NEEDED) Shared library: [libmpi_gnu_91.so.12]
0x0000000000000001 (NEEDED) Shared library: [libxpmem.so.0]
0x0000000000000001 (NEEDED) Shared library: [libm.so.6]
0x0000000000000001 (NEEDED) Shared library: [libstdc++.so.6]
0x0000000000000001 (NEEDED) Shared library: [libgcc_s.so.1]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
0x000000000000000e (SONAME) Library soname: [libspfft.so.1]
0x000000000000000f (RPATH) Library rpath: [/project/d110/timuel/spack/opt/spack/cray-sles15-zen2/gcc-10.2.0/spfft-1.0.3-meadkxxxregbcgl43lrhm4tb26vrs6o3/lib:/project/d110/timuel/spack/opt/spack/cray-sles15-zen2/gcc-10.2.0/spfft-1.0.3-meadkxxxregbcgl43lrhm4tb26vrs6o3/lib64:/opt/cray/pe/fftw/3.3.8.9/x86_rome/lib:/opt/cray/pe/mpich/8.1.4/ofi/gnu/9.1/lib:/opt/gcc/10.2.0/snos:/project/d110/timuel/spack/opt/spack/cray-sles15-zen2/gcc-10.2.0/spfft-1.0.3-meadkxxxregbcgl43lrhm4tb26vrs6o3/lib:/project/d110/timuel/spack/opt/spack/cray-sles15-zen2/gcc-10.2.0/spfft-1.0.3-meadkxxxregbcgl43lrhm4tb26vrs6o3/lib64:/opt/cray/pe/fftw/3.3.8.9/x86_rome/lib:/opt/cray/pe/mpich/8.1.4/ofi/gnu/9.1/lib]
0x000000000000000c (INIT) 0x7dd8
0x000000000000000d (FINI) 0x2fa68
0x0000000000000019 (INIT_ARRAY) 0x2381b8
0x000000000000001b (INIT_ARRAYSZ) 8 (bytes)
0x000000000000001a (FINI_ARRAY) 0x2381c0
0x000000000000001c (FINI_ARRAYSZ) 8 (bytes)
0x0000000000000004 (HASH) 0x190
0x000000006ffffef5 (GNU_HASH) 0x8c0
0x0000000000000005 (STRTAB) 0x2638
0x0000000000000006 (SYMTAB) 0xdc0
0x000000000000000a (STRSZ) 9990 (bytes)
0x000000000000000b (SYMENT) 24 (bytes)
0x0000000000000003 (PLTGOT) 0x239000
0x0000000000000002 (PLTRELSZ) 3456 (bytes)
0x0000000000000014 (PLTREL) RELA
0x0000000000000017 (JMPREL) 0x7058
0x0000000000000007 (RELA) 0x5078
0x0000000000000008 (RELASZ) 8160 (bytes)
0x0000000000000009 (RELAENT) 24 (bytes)
0x000000006ffffffe (VERNEED) 0x4f48
0x000000006fffffff (VERNEEDNUM) 5
0x000000006ffffff0 (VERSYM) 0x4d3e
0x000000006ffffff9 (RELACOUNT) 217
0x0000000000000000 (NULL) 0x0
Thanks for reporting this.
The issue of linking to libfftw3f
, when it is not required, should now be fixed by b27601a in the develop branch.
I don't see anything within SpFFT to cause linking to libfftw3_threads
and libfftw3_mpi
, so I think that might be caused by setting CMake linking flags externally. On my local machine with macOS, I could not observe this issue (manual build and with Spack).
@AdhocMan thanks for the fix, I'll test it. Depending on your default linker flags (distros nowadays often carry an implicit -Wl,--as-needed
) it might be automatically removed when no symbols were used from a library afaik. At least within the Spack package I couldn't find a hint that the FFTW libraries were set explicitly, but I'll check the CMake log when rebuilding.