>
> These are the targets currently exported by CMake's FindGTest.
>
> Remove the GTest…::GTest, and GTest::Main targets which deprecated in
> CMake 3.20, and removed in CMake 4.1.0.
Fine to me, just double-checking 😃
---
### Author:  [@dzenanz](https://discourse.itk.org/u/dzenanz)
#### Post date: [April 10, 2026, 6:13pm UTC](https://discourse.itk.org/t/patches-for-itk-5-4-6/7745/7 "2026-04-10T18:13:47Z")
Maybe `3b3c1e15bb5cdcbd83f061f9968a2704fe9e9baf` from [PR 6002](https://github.com/InsightSoftwareConsortium/ITK/pull/6002)?
---
### Author:  [@matt.mccormick](https://discourse.itk.org/u/matt.mccormick)
#### Post date: [April 10, 2026, 7:58pm UTC](https://discourse.itk.org/t/patches-for-itk-5-4-6/7745/8 "2026-04-10T19:58:52Z")
> [@Niels\_Dekker](#):
>
> So the following pull request is for ITK 6, not for ITK 5.4.6:
@Niels_Dekker correct – the names are not changing in ITK 5.
---
### Author:  [@matt.mccormick](https://discourse.itk.org/u/matt.mccormick)
#### Post date: [April 10, 2026, 7:59pm UTC](https://discourse.itk.org/t/patches-for-itk-5-4-6/7745/9 "2026-04-10T19:59:23Z")
@dzenanz please review: [COMP: Move inline = default destructors to .cxx for 30 exported classes by thewtex · Pull Request #6041 · InsightSoftwareConsortium/ITK · GitHub](https://github.com/InsightSoftwareConsortium/ITK/pull/6041)
---
### Author:  [@blowekamp](https://discourse.itk.org/u/blowekamp)
#### Post date: [April 13, 2026, 1:49pm UTC](https://discourse.itk.org/t/patches-for-itk-5-4-6/7745/10 "2026-04-13T13:49:33Z")
We should also consider a full update to GDCM or apply critical patched to the thridparty GDCM library.
---
### Author:  [@hjmjohnson](https://discourse.itk.org/u/hjmjohnson)
#### Post date: [April 13, 2026, 9:30pm UTC](https://discourse.itk.org/t/patches-for-itk-5-4-6/7745/11 "2026-04-13T21:30:02Z")
_Two_ _additional_ _items_ _for_ _5.4.6_ _consideration:_
[TODO as of 20260413] _ **PEP** _ _ **688** _ _ **buffer** _ _ **protocol** _ _ **and** _ _ **GIL** _ _ **release** _ _ **safety** _ _**(**_#6042\*\*\*,\*\*\* #6043\*\*\*)\*\*\*
▎ _PRs_ [ENH: Backport #6026 — PEP 688 buffer protocol and np.asarray() lifetime safety by hjmjohnson · Pull Request #6042 · InsightSoftwareConsortium/ITK · GitHub](https://github.com/InsightSoftwareConsortium/ITK/pull/6042) _and_ [ENH: Backport #6027 — comprehensive tests for itk.Image buffer protocol and lifetime by hjmjohnson · Pull Request #6043 · InsightSoftwareConsortium/ITK · GitHub](https://github.com/InsightSoftwareConsortium/ITK/pull/6043) _backport_ _the_ _PEP_ _688_ _buffer_ _protocol_
_(\_buffer_\_/\__release\_buffer_\_) _and_ _comprehensive_ _lifetime_ _safety_ _tests_ _from_ _main._ _These_ _fix_ _np.asarray(itk\_image) to_ _work_ _correctly_ _with_ _Python_ _3.12+_ _and_ _prevent_
_use-after-free_ _when_ _the_ _backing_ _ITK_ _image_ _is_ _garbage_ _collected._ _Both_ _PRs_ _target_ _release-5.4 and_ _CI_ _is_ _pending._
and 1 done
[DONE] _ **Backport** _ _ **FFTW** _ _ **feature** _ _ **selections** _ _**(**_#6025\*\*\*)\*\*\*
_Issue_ [Backport #6007 For FFTW feature selections to release-5.4 · Issue #6025 · InsightSoftwareConsortium/ITK · GitHub](https://github.com/InsightSoftwareConsortium/ITK/issues/6025) _requests_ _backporting_ _PR_ [PERF: Use ABI-guaranteed SIMD baselines for redistribution-safe FFTW builds by hjmjohnson · Pull Request #6007 · InsightSoftwareConsortium/ITK · GitHub](https://github.com/InsightSoftwareConsortium/ITK/pull/6007) _("PERF:_ _Use_
_ABI-guaranteed_ _SIMD_ _baselines_ _for_ _redistribution-safe_ _FFTW_ _builds"),_ _which_ _was_ _merged_ _to_ _main_ _on_ _2026-04-08._ _The_ _current_ _release-5.4_ _FFTW_ _configuration_ _has_ _pitfalls_ _in_
_cross-platform_ _environments_ _that_ #6007 _resolves._ _The_ _FFTW_ _SIMD_ _codelet_ _changes_ _are_ _already_ _partially_ _staged_ _(per_ _Post_ #1\*),\* _but_ _the_ _full_ _feature-selection_ _mechanism_ _from_
#6007 _is_ _more_ _robust._
---
### Author:  [@hjmjohnson](https://discourse.itk.org/u/hjmjohnson)
#### Post date: [April 13, 2026, 9:32pm UTC](https://discourse.itk.org/t/patches-for-itk-5-4-6/7745/12 "2026-04-13T21:32:49Z")
My vote is to do a full update. that seems like the path of least resistance.
---
### Author:  [@hjmjohnson](https://discourse.itk.org/u/hjmjohnson)
#### Post date: [April 13, 2026, 9:46pm UTC](https://discourse.itk.org/t/patches-for-itk-5-4-6/7745/13 "2026-04-13T21:46:49Z")
I’ve created a tracking issue with a prioritized list of backport candidates from `main`:
[Backport candidates for ITK 5.4.6 release · Issue #6051 · InsightSoftwareConsortium/ITK · GitHub](https://github.com/InsightSoftwareConsortium/ITK/issues/6051)
It includes 7 Tier 1 critical bug fixes (all 1–3 file cherry-picks), 3 Tier 2 high-value fixes, 4 Tier 3 build fixes for modern toolchains, and the GDCM CVE @blowekamp mentioned. PRs #6041, #6042, #6043 are already merged to `release-5.4`; #6022 and #6025 are still open.
@matt.mccormick — happy to open backport PRs for any of the Tier 1 items.
Created: [Backport candidates for ITK 5.4.6 release · Issue #6051 · InsightSoftwareConsortium/ITK · GitHub](https://github.com/InsightSoftwareConsortium/ITK/issues/6051)
---
### Author:  [@matt.mccormick](https://discourse.itk.org/u/matt.mccormick)
#### Post date: [April 14, 2026, 1:24pm UTC](https://discourse.itk.org/t/patches-for-itk-5-4-6/7745/14 "2026-04-14T13:24:10Z")
> [@hjmjohnson](#):
>
> @matt.mccormick — happy to open backport PRs for any of the Tier 1 items.
@hjmjohnson great, could you please create PR’s for the Tier 1 patches?
---
### Author:  [@matt.mccormick](https://discourse.itk.org/u/matt.mccormick)
#### Post date: [April 14, 2026, 1:56pm UTC](https://discourse.itk.org/t/patches-for-itk-5-4-6/7745/15 "2026-04-14T13:56:24Z")
> We should also consider a full update to GDCM or apply critical patched to the thridparty GDCM library.
This updates to current GDCM `release` [Release 5.4 update gdcm by thewtex · Pull Request #6059 · InsightSoftwareConsortium/ITK · GitHub](https://github.com/InsightSoftwareConsortium/ITK/pull/6059)
Still todo is a patch for CVE-2026-3650
---
### Author:  [@imikejackson](https://discourse.itk.org/u/imikejackson)
#### Post date: [April 26, 2026, 10:11pm UTC](https://discourse.itk.org/t/patches-for-itk-5-4-6/7745/16 "2026-04-26T22:11:09Z")
I am probably too late for this but there is a one liner issue that causes the ITK Lib Tiff to crash on unknown tiff tags due to a nullptr bug. It only effects Windows builds.
---
### Author:  [@JDuffeyBQ](https://discourse.itk.org/u/JDuffeyBQ)
#### Post date: [April 27, 2026, 1:37pm UTC](https://discourse.itk.org/t/patches-for-itk-5-4-6/7745/17 "2026-04-27T13:37:20Z")
Here’s the issue we’ve submitted.
>
>
> \### Description
>
>
>
> The following bug was encountered when using the conda forge …package of ITK, but it will occur on when building on Windows with external libTIFF in general.
>
> When using ITK 5 built with external libTIFF certain TIFF files will cause \`TIFFImageIO\` to crash when reading their tags. Specifically inside \`TIFFImageIO::ReadImageInformation()\` and then the private \`TIFFImageIO::ReadTIFFTags()\`.
>
> There is a workaround for versions 4.0.0-4.0.2 of libTIFF based on the value of \`ITK\_TIFF\_HAS\_TIFFFieldReadCount\`. This macro define is from \`Modules/ThirdParty/TIFF/CMakeLists.txt\` via \`check\_type\_size(TIFFFieldReadCount ITK\_TIFF\_HAS\_TIFFFieldReadCount)\`. The CMake function \`check\_type\_size\` uses \`sizeof(TIFFFieldReadCount)\` to determine if the function exists or not. However this is not legal to use function types in \`sizeof\` according to the standard. GCC and Clang accept this by default for C programs (and rejects it by default for C++) but MSVC rejects it. The correct form would be \`sizeof(&TIFFFieldReadCount)\` and \`check\_type\_size(&TIFFFieldReadCount ITK\_TIFF\_HAS\_TIFFFieldReadCount)\`.
>
> This means that on Windows with external libTIFF the wrong code is using for accessing TIFF fields. The workaround reproduces internal libTIFF structures that are no longer correct and invalid data is read. In my case it read a 0 into \`field\_name\` and crashes later when attempting to deference the null pointer while logging that the data type is unsupported.
>
> Attached is a file that reproduces this issue.
>
> \[itk\_crash.zip\](https://github.com/user-attachments/files/27127504/itk\_crash.zip)
>
> \### Steps to Reproduce
>
>
>
> \`\`\`
> conda install libitk-devel=5.4.5
> \`\`\`
>
> \`\`\`cmake
> cmake\_minimum\_required(VERSION 3.30)
>
> project(itk\_crash LANGUAGES CXX)
>
> add\_executable(itk\_crash main.cpp)
>
> find\_package(ITK REQUIRED COMPONENTS ITKIOTIFF)
>
> target\_link\_libraries(itk\_crash PRIVATE ITKIOTIFF)
> \`\`\`
>
> \`\`\`cpp
> \#include \
>
> int main()
> {
> itk::TIFFImageIO::Pointer imageIO = itk::TIFFImageIO::New();
> imageIO-\>SetFileName("./itk\_crash.tif");
> imageIO-\>ReadImageInformation();
> }
> \`\`\`
>
> \### Expected behavior
>
>
>
> No crash but should have this error message.
>
> \`\`\`
> WARNING: In C:\\P\\IPP\\ITK-source\\ITK\\Modules\\IO\\TIFF\\src\\itkTIFFImageIO.cxx, line 1264
> TIFFImageIO (0000020FE6411100): ICC Profile has unsupported data type (7) for meta-data dictionary.
> \`\`\`
>
> \### Actual behavior
>
>
>
> If attached to debugger:
> \`\`\`none
> Exception thrown at 0x00007FFC40F55F31 (ucrtbase.dll) in itk\_crash.exe: 0xC0000005: Access violation reading location 0x0000000000000000.
> \`\`\`
>
> \### Reproducibility
>
>
>
> 100%
>
> \### Versions
>
>
>
> ITK
>
> 5.4.5
>
> conda-forge/win-64::libitk-5.4.5-hb27c29c\_0
> conda-forge/win-64::libitk-devel-5.4.5-h7f67dcf\_0
> conda-forge/win-64::libtiff-4.7.1-h8f73337\_1
>
> \### Environment
>
>
>
> Windows
> Python 3.12
> conda 24.1.2
>
> \### Additional Information
>
>
>
> None
---
### Author:  [@dzenanz](https://discourse.itk.org/u/dzenanz)
#### Post date: [April 27, 2026, 4:07pm UTC](https://discourse.itk.org/t/patches-for-itk-5-4-6/7745/18 "2026-04-27T16:07:42Z")
5.4.6 has been tagged. There is more detail in this [tracking issue](https://github.com/InsightSoftwareConsortium/ITK/issues/6092).
@blowekamp can [PR #6150](https://github.com/InsightSoftwareConsortium/ITK/pull/6150) be easily backported to `release-5.4` branch?
---
### Author:  [@blowekamp](https://discourse.itk.org/u/blowekamp)
#### Post date: [April 27, 2026, 4:11pm UTC](https://discourse.itk.org/t/patches-for-itk-5-4-6/7745/19 "2026-04-27T16:11:38Z")
This issue only effects the 5.4 branch. The version requirement for libtiff has been increased, and this check is not longer required.
I also have a PR for the conda-forge feedstock:
>
>
> \## Summary
>
> Applies the fix from upstream ITK PR \[InsightSoftwareConsortium/ITK#…6150\](https://github.com/InsightSoftwareConsortium/ITK/pull/6150) as a recipe patch.
>
> \### Bug
>
> When building with \`ITK\_USE\_SYSTEM\_TIFF=ON\` (always the case in this feedstock), the CMake detection of \`TIFFFieldReadCount\` used \`check\_type\_size()\`, which internally calls \`sizeof()\` on the argument. Passing a \*\*function\*\* name to \`sizeof()\` is non-standard — GCC and Clang accept it as an extension, but MSVC rejects it — so \`ITK\_TIFF\_HAS\_TIFFFieldReadCount\` was never defined on Windows builds.
>
> Without that define, \`itkTIFFImageIO\` falls through to a libtiff 4.0.0–4.0.2 workaround that directly accesses the internal \`\_TIFFField\` struct. That struct layout is no longer correct for modern libtiff versions, causing reads of garbage data and \*\*NULL pointer crashes\*\* when encountering tags with unsupported data types (e.g. an ICC profile tag).
>
> Fixes: \[InsightSoftwareConsortium/ITK#6148\](https://github.com/InsightSoftwareConsortium/ITK/issues/6148)
>
> \### Fix
>
> Replace \`check\_type\_size(TIFFFieldReadCount ...)\` with \`check\_symbol\_exists(TIFFFieldReadCount "tiffio.h" ...)\` in \`Modules/ThirdParty/TIFF/CMakeLists.txt\`, which correctly detects the function symbol on all compilers.
>
> \### Changes
>
> \- \`recipe/0001-BUG-use-check\_symbol\_exists-for-TIFFFieldReadCount.patch\` — new patch applying the upstream fix
> \- \`recipe/meta.yaml\` — add \`patches:\` list, bump build number 2 → 3
---
### Author:  [@seanm](https://discourse.itk.org/u/seanm)
#### Post date: [May 4, 2026, 4:33pm UTC](https://discourse.itk.org/t/patches-for-itk-5-4-6/7745/20 "2026-05-04T16:33:41Z")
> [@matt.mccormick](#):
>
> Are there other patches that are missing?
Ah darn, I didn’t notice this thread.
If there’s a 5.4.7 can we backport: [Fixed compilation errors with C23, and one with C++ by seanm · Pull Request #985 · vxl/vxl · GitHub](https://github.com/vxl/vxl/pull/985)
Otherwise, building fails with:
```auto
CMake Error at Modules/ThirdParty/VNL/src/vxl/CMakeLists.txt:48 (MESSAGE):
CMAKE_C_STANDARD:STRING=17 not in know standards list
90;99;11.
```