Skip to content

Configuration fails with FFTW #5759

Description

@SimonRit

Description

Configuring my ITK projection on Linux with ITK_USE_FFTWF and ITK_USE_FFTWD generates the following error since #5721:

CMake Error in Modules/Filtering/FFT/src/CMakeLists.txt:
  Target "ITKFFT" INTERFACE_LINK_DIRECTORIES property contains path:

    "/home/srit/src/itk/lin64/fftw/lib"

  which is prefixed in the build directory.

Steps to Reproduce

Clone ITK main and configure with cmake -DITK_USE_FFTWF=ON -DITK_USE_FFTWD=ON ITK_SOURCE_DIR

Reproducibility

100%

Versions

Environment

Ubuntu

Activity

  1. added
    type:BugInconsistencies or issues which will cause an incorrect result under some or all circumstances
    on Feb 3, 2026
  2. SimonRit commented on Feb 3, 2026

    @SimonRit
    Author

    Any suggestion @blowekamp?

  3. blowekamp commented on Feb 3, 2026

    @blowekamp
    Member

    I am looking into it. It looks like the issue does not occur with a system FFTW.

  4. SimonRit commented on Feb 3, 2026

    @SimonRit
    Author

    Yes, it doesn't occur with a system FFTW. Which I'm now using :-).

  5. blowekamp commented on Feb 3, 2026

    @blowekamp
    Member

    The issue seem to be:
    set(ITKFFT_SYSTEM_LIBRARY_DIRS ${FFTW_LIBDIR})

    This is likely not needed for the ITK build External Project of FFTW. There is a fair amount of which could be updated related to the FFT back ends. Here is a quick fix that seemed to work for me, in build and install.

    diff --git a/CMake/itkExternal_FFTW.cmake b/CMake/itkExternal_FFTW.cmake
    index 6369eaeeb9..e5c3693913 100644
    --- a/CMake/itkExternal_FFTW.cmake
    +++ b/CMake/itkExternal_FFTW.cmake
    @@ -113,7 +113,6 @@ if(NOT ITK_USE_SYSTEM_FFTW)
    ${FFTW_STAGED_INSTALL_PREFIX}/${CMAKE_INSTALL_LIBDIR}
    )
    set(FFTW_INCLUDE ${FFTW3_INCLUDE_DIRS})

    • set(FFTW_LIBDIR ${FFTW3_LIBRARY_DIRS})
      set(
      ITK_FFTWF_LIBRARIES_NAMES
      fftw3f_threads
      @@ -173,7 +172,6 @@ if(NOT ITK_USE_SYSTEM_FFTW)
      )

      set(FFTW_INCLUDE ${FFTW3_INCLUDE_DIRS})

    • set(FFTW_LIBDIR ${FFTW3_LIBRARY_DIRS})
      set(
      ITK_FFTWD_LIBRARIES_NAMES
      fftw3_threads

  6. SimonRit commented on Feb 3, 2026

    @SimonRit
    Author

    Works for me, thanks, but will this work for a system FFTW compiled in a non-system directory? should we remove it only if(NOT ITK_USE_SYSTEM_FFTW)?

  7. blowekamp commented on Feb 5, 2026

    @blowekamp
    Member

    The "build in" FFTW uses an ExternalProject to compile the FFTW library, and a manual installation of some files. This is not a robust/correct installation that can easily work with CMake targets/interfaces. Additionally, the ITK FFTW "option" also supports Intel's MKL, and an OpenCV FFTW library. These are all top level configurations. There a need to refactorthe FFTW options into a ThirdParty library with a ITK::ITKFFTWModule interface.

    In the mean time a change like the following may mostly work the way the existing code did:
    --- a/CMake/itkExternal_FFTW.cmake
    +++ b/CMake/itkExternal_FFTW.cmake
    @@ -110,7 +110,7 @@ if(NOT ITK_USE_SYSTEM_FFTW)
    set(FFTW3f_INCLUDE_DIRS ${FFTW_STAGED_INSTALL_PREFIX}/include)
    set(
    FFTW3f_LIBRARY_DIRS

    •  ${FFTW_STAGED_INSTALL_PREFIX}/${CMAKE_INSTALL_LIBDIR}
      
    •  $<BUILD_INTERFACE:${FFTW_STAGED_INSTALL_PREFIX}/${CMAKE_INSTALL_LIBDIR}>
      
      )

    However when ITK is installed it would not be correct, like the existing code.

  8. dzenanz commented on Feb 5, 2026

    @dzenanz
    Member

    Between @blowekamp and @SimonRit, is there enough appetite to do the proper refactoring? If not, backwards-equivalent fix from previous comment should be applied soon.

  9. blowekamp commented on Feb 5, 2026

    @blowekamp
    Member

    Between @blowekamp and @SimonRit, is there enough appetite to do the proper refactoring? If not, backwards-equivalent fix from previous comment should be applied soon.

    Actually, removing the FFTW3f_LIBRARY_DIRS and changing to a full path for the libraries, with a generator expression for build, and install maybe closer and a better solution than suggested above.

    There are still quite a few issue with the changes I'm trying to work through, so only quicker solution at the moment from me.

  10. SimonRit commented on Feb 5, 2026

    @SimonRit
    Author

    Between @blowekamp and @SimonRit, is there enough appetite to do the proper refactoring? If not, backwards-equivalent fix from previous comment should be applied soon.

    Sorry I'll pass. I would need a proper training in modern CMake before being able to code something useful.

  11. dzenanz commented on Feb 5, 2026

    @dzenanz
    Member

    Brad, can you propose the PR with the quicker fix?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

type:BugInconsistencies or issues which will cause an incorrect result under some or all circumstances

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions