eth-cscs/SpFFT

Always linked against fftw3f even when single precision is not requested

dev-zero opened this issue · 2 comments

The consequence of the current logic

if(_FFTW_FLOAT_LIBRARY AND FFTW_FOUND)
list(APPEND FFTW_LIBRARIES ${_FFTW_FLOAT_LIBRARY})
set(FFTW_FLOAT_FOUND TRUE)
else()
set(FFTW_FLOAT_FOUND FALSE)
endif()

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.