### Author:  [@matt.mccormick](https://discourse.itk.org/u/matt.mccormick)
#### Post date: [July 3, 2026, 6:24pm UTC](https://discourse.itk.org/t/patches-for-itk-5-4-7/7780/1 "2026-07-03T18:24:18Z")
Hi folks,
The next patch (bugfix) release, ITK 5.4.7, is coming up.
Patches currently staged on the Git `release-5.4` branch include:
```auto
Andras Lasso (1):
BUG: Fix image file reader crash when axis direction vector is short
Bradley Lowekamp (2):
BUG: Use check_symbol_exists for TIFFFieldReadCount detection
BUG: Replace std::abs with std::fabs to avoid ambiguity
Csaba Pinter (1):
ENH: Support 5D files in NRRD IO
Hans J. Johnson (13):
BUG: Allow '.' and '+' in -march/-mtune strip regex (issue #6133)
COMP: Add ccache support and pixi CI tasks to release-5.4
COMP: Backport GitHub Actions cache-management workflows to release-5.4
COMP: Use pixi CI tasks and cache ccache in release-5.4 pixi workflow
COMP: Add ccache caching to release-5.4 Azure pipelines
COMP: Add ccache caching to release-5.4 macOS-arm workflow
BUG: Set FFTW_INCLUDE from FFTW3f_INCLUDE_DIRS in FFTWF-only builds
BUG: Register FFTW factory only for configured precisions
COMP: Include fftw3.h directly in FFTW filter headers
BUG: Make 1D FFT tests build with single-precision FFTW
COMP: Restrict CurvatureRegistrationFilter to ITK_USE_FFTWD builds
PERF: Hoist constant tensor-basis SVD out of the per-voxel DTI loop
ENH: Add single-image-path test for DTI tensor reconstruction
James Butler (1):
COMP: Update DCMTK targets based on new DCMTK namespace
```
Are there other patches that are missing? Patches should be critical bugfixes, improved support for compilers, and documentation fixes.
---
### Author:  [@simon.rit](https://discourse.itk.org/u/simon.rit)
#### Post date: [July 4, 2026, 2:33pm UTC](https://discourse.itk.org/t/patches-for-itk-5-4-7/7780/2 "2026-07-04T14:33:17Z")
Thanks for asking. I have two warnings I’d like to address if possible before the release, see [GDCM warnings on release-5.4 barnch · Issue #6551 · InsightSoftwareConsortium/ITK · GitHub](https://github.com/InsightSoftwareConsortium/ITK/issues/6551). Any suggestion on how to solve them?
---
### Author:  [@blowekamp](https://discourse.itk.org/u/blowekamp)
#### Post date: [July 4, 2026, 3:21pm UTC](https://discourse.itk.org/t/patches-for-itk-5-4-7/7780/3 "2026-07-04T15:21:35Z")
> [@simon.rit](#):
>
> o warnings I’d like to address if possible before the release
We may just want to update GDCM to its most recent release, due to bug and security patches.
---
### Author:  [@seanm](https://discourse.itk.org/u/seanm)
#### Post date: [July 6, 2026, 12:28am UTC](https://discourse.itk.org/t/patches-for-itk-5-4-7/7780/4 "2026-07-06T00:28:47Z")
If it’s not already, can we get the fix to let vnl compile with modern C dialects?
>
>
> Resolves: #983 to allow building with C17 or C23
>
> Update default compiler to C11… CXX11
---
### Author:  [@matt.mccormick](https://discourse.itk.org/u/matt.mccormick)
#### Post date: [July 6, 2026, 6:32pm UTC](https://discourse.itk.org/t/patches-for-itk-5-4-7/7780/5 "2026-07-06T18:32:18Z")
Please take a look at:
>
>
> \## Summary
>
> Fixes the CMake configure-time deprecation warnings reported in #655…1, which appear on \`release-5.4\` (RTK nightly builds, Linux and Windows) but not on \`main\`:
>
> \`\`\`
> CMake Warning at Modules/ThirdParty/GDCM/src/gdcm/CMakeLists.txt:...
> EXECUTABLE\_OUTPUT\_PATH is deprecated. Use CMAKE\_RUNTIME\_OUTPUT\_DIRECTORY instead.
>
> CMake Warning at Modules/ThirdParty/GDCM/src/gdcm/CMakeLists.txt:...
> LIBRARY\_OUTPUT\_PATH is deprecated. Use CMAKE\_LIBRARY\_OUTPUT\_DIRECTORY and
> CMAKE\_ARCHIVE\_OUTPUT\_DIRECTORY instead.
> \`\`\`
>
> \## Root cause
>
> The warnings are \*emitted\* by the vendored \`Modules/ThirdParty/GDCM/src/gdcm/CMakeLists.txt\`, whose newer compatibility shim warns whenever the legacy \`EXECUTABLE\_OUTPUT\_PATH\` / \`LIBRARY\_OUTPUT\_PATH\` variables are set:
>
> \`\`\`cmake
> if(EXECUTABLE\_OUTPUT\_PATH)
> set(CMAKE\_RUNTIME\_OUTPUT\_DIRECTORY ${EXECUTABLE\_OUTPUT\_PATH})
> message(WARNING "EXECUTABLE\_OUTPUT\_PATH is deprecated. ...")
> endif()
> if(LIBRARY\_OUTPUT\_PATH)
> ...
> message(WARNING "LIBRARY\_OUTPUT\_PATH is deprecated. ...")
> endif()
> \`\`\`
>
> They are \*triggered\* by ITK's own wrapper one level up, \`Modules/ThirdParty/GDCM/src/CMakeLists.txt\`, which set both deprecated variables in the parent scope immediately before \`add\_subdirectory(gdcm)\`:
>
> \`\`\`cmake
> \# GDCM uses these to refer to executable and library locations
> set(EXECUTABLE\_OUTPUT\_PATH ${CMAKE\_RUNTIME\_OUTPUT\_DIRECTORY})
> set(LIBRARY\_OUTPUT\_PATH ${CMAKE\_LIBRARY\_OUTPUT\_DIRECTORY})
> \`\`\`
>
> The \`src/gdcm/\` subtree portion of the shim landed on \`release-5.4\` via the GDCM upstream update in #6059, but the corresponding wrapper cleanup was never backported — so on \`release-5.4\` the shim sees the variables set and warns, while \`main\` (which already dropped these \`set()\` calls) is silent.
>
> \## Fix
>
> Backport of commit d5cf8de3ed33039499315163bdd9682f01ed573c ("ENH: Conform GDCM to use CMAKE\_\*OUTPUT\_DIRECTORY"), applying only the \`src/CMakeLists.txt\` wrapper hunk — removing the two \`set()\` calls. The \`src/gdcm/CMakeLists.txt\` portion of that commit is already present on \`release-5.4\` (verified byte-identical), so it is intentionally omitted to avoid disturbing the vendored update.
>
> With the wrapper no longer setting the legacy variables, the vendored shim's \`if()\` guards are false and the two \`message(WARNING ...)\` calls no longer fire. The vendored GDCM CMake still derives \`EXECUTABLE\_OUTPUT\_PATH\` / \`LIBRARY\_OUTPUT\_PATH\` internally from \`CMAKE\_RUNTIME\_OUTPUT\_DIRECTORY\` / \`CMAKE\_LIBRARY\_OUTPUT\_DIRECTORY\` / \`CMAKE\_ARCHIVE\_OUTPUT\_DIRECTORY\` for its own use, so build output locations are unchanged.
>
> This is a configuration-only change; no C++ is affected.
>
> Fixes #6551.
>
> 🤖 Generated with \[Claude Code\](https://claude.com/claude-code)
---
### Author:  [@matt.mccormick](https://discourse.itk.org/u/matt.mccormick)
#### Post date: [July 6, 2026, 6:32pm UTC](https://discourse.itk.org/t/patches-for-itk-5-4-7/7780/6 "2026-07-06T18:32:51Z")
Yes, please see
>
>
> \## Summary
>
> Fixes the CMake configure-time deprecation warnings reported in #655…1, which appear on \`release-5.4\` (RTK nightly builds, Linux and Windows) but not on \`main\`:
>
> \`\`\`
> CMake Warning at Modules/ThirdParty/GDCM/src/gdcm/CMakeLists.txt:...
> EXECUTABLE\_OUTPUT\_PATH is deprecated. Use CMAKE\_RUNTIME\_OUTPUT\_DIRECTORY instead.
>
> CMake Warning at Modules/ThirdParty/GDCM/src/gdcm/CMakeLists.txt:...
> LIBRARY\_OUTPUT\_PATH is deprecated. Use CMAKE\_LIBRARY\_OUTPUT\_DIRECTORY and
> CMAKE\_ARCHIVE\_OUTPUT\_DIRECTORY instead.
> \`\`\`
>
> \## Root cause
>
> The warnings are \*emitted\* by the vendored \`Modules/ThirdParty/GDCM/src/gdcm/CMakeLists.txt\`, whose newer compatibility shim warns whenever the legacy \`EXECUTABLE\_OUTPUT\_PATH\` / \`LIBRARY\_OUTPUT\_PATH\` variables are set:
>
> \`\`\`cmake
> if(EXECUTABLE\_OUTPUT\_PATH)
> set(CMAKE\_RUNTIME\_OUTPUT\_DIRECTORY ${EXECUTABLE\_OUTPUT\_PATH})
> message(WARNING "EXECUTABLE\_OUTPUT\_PATH is deprecated. ...")
> endif()
> if(LIBRARY\_OUTPUT\_PATH)
> ...
> message(WARNING "LIBRARY\_OUTPUT\_PATH is deprecated. ...")
> endif()
> \`\`\`
>
> They are \*triggered\* by ITK's own wrapper one level up, \`Modules/ThirdParty/GDCM/src/CMakeLists.txt\`, which set both deprecated variables in the parent scope immediately before \`add\_subdirectory(gdcm)\`:
>
> \`\`\`cmake
> \# GDCM uses these to refer to executable and library locations
> set(EXECUTABLE\_OUTPUT\_PATH ${CMAKE\_RUNTIME\_OUTPUT\_DIRECTORY})
> set(LIBRARY\_OUTPUT\_PATH ${CMAKE\_LIBRARY\_OUTPUT\_DIRECTORY})
> \`\`\`
>
> The \`src/gdcm/\` subtree portion of the shim landed on \`release-5.4\` via the GDCM upstream update in #6059, but the corresponding wrapper cleanup was never backported — so on \`release-5.4\` the shim sees the variables set and warns, while \`main\` (which already dropped these \`set()\` calls) is silent.
>
> \## Fix
>
> Backport of commit d5cf8de3ed33039499315163bdd9682f01ed573c ("ENH: Conform GDCM to use CMAKE\_\*OUTPUT\_DIRECTORY"), applying only the \`src/CMakeLists.txt\` wrapper hunk — removing the two \`set()\` calls. The \`src/gdcm/CMakeLists.txt\` portion of that commit is already present on \`release-5.4\` (verified byte-identical), so it is intentionally omitted to avoid disturbing the vendored update.
>
> With the wrapper no longer setting the legacy variables, the vendored shim's \`if()\` guards are false and the two \`message(WARNING ...)\` calls no longer fire. The vendored GDCM CMake still derives \`EXECUTABLE\_OUTPUT\_PATH\` / \`LIBRARY\_OUTPUT\_PATH\` internally from \`CMAKE\_RUNTIME\_OUTPUT\_DIRECTORY\` / \`CMAKE\_LIBRARY\_OUTPUT\_DIRECTORY\` / \`CMAKE\_ARCHIVE\_OUTPUT\_DIRECTORY\` for its own use, so build output locations are unchanged.
>
> This is a configuration-only change; no C++ is affected.
>
> Fixes #6551.
>
> 🤖 Generated with \[Claude Code\](https://claude.com/claude-code)
---
### Author:  [@matt.mccormick](https://discourse.itk.org/u/matt.mccormick)
#### Post date: [July 6, 2026, 6:33pm UTC](https://discourse.itk.org/t/patches-for-itk-5-4-7/7780/7 "2026-07-06T18:33:51Z")
I tried updating our vendored GDCM – GDCM did not have the fix yet for `release-5.4`
---
### Author:  [@JosetteLeonard](https://discourse.itk.org/u/JosetteLeonard)
#### Post date: [July 24, 2026, 1:26pm UTC](https://discourse.itk.org/t/patches-for-itk-5-4-7/7780/8 "2026-07-24T13:26:32Z")
GDCM warnings downstream are painful. Probably worth including if the fixes stay contained, but scope really does matter for a patch release.