Re-configuration fails on release-5.4

[SimonRit]

Description

#6557 aimed at fixing #6616 for release-5.4. I did remove GDCM warnings after the first pass (see here) but the warning came back after a subsequent cmake in a continous build and it caused compilation errors on Linux (see here).

Steps to Reproduce

The following commands produces the compilation errors

cmake ../itk -DBUILD_TESTING:BOOL=OFF
make
cmake .
make

Expected behavior

Actual behavior

Compilation errors, see here.

Reproducibility

100%

Versions

Branch release-5.4

Environment

Warnings on Windows, errors on Linux.

Additional Information

[SimonRit]

cc @thewtex

[hjmjohnson]

Reproduced on release-5.4 (c8721a5) with the Unix Makefiles generator. Root cause is a stale EXECUTABLE_OUTPUT_PATH/LIBRARY_OUTPUT_PATH cache entry written by GDCM's vendored OpenJPEG, which resolves to the literal path /bin. #6557 did not cause this — it removed the normal-variable shadow that had been masking it since the GDCM 3.2.x import.

The fix is a three-line deletion in Modules/ThirdParty/GDCM/src/gdcm/Utilities/gdcmopenjpeg/CMakeLists.txt; verified green locally. Note that no GDCM release fixes this — v3.2.8, v3.2.9, v3.2.10 and master all carry the defect identically, so bumping the tag is not an option.

Root cause

Three ingredients, all in the vendored GDCM tree:

1. Utilities/gdcmopenjpeg/CMakeLists.txt:180-181 writes cache entries that persist across configures:

   set (EXECUTABLE_OUTPUT_PATH ${OPENJPEG_BINARY_DIR}/bin CACHE PATH "...")
   set (LIBRARY_OUTPUT_PATH ${OPENJPEG_BINARY_DIR}/bin CACHE PATH "...")

2. OPENJPEG_BINARY_DIR is empty. Utilities/CMakeLists.txt:26 sets OPENJPEG_NAMESPACE "GDCMOPENJPEG", so project(${OPENJPEG_NAMESPACE} C) defines GDCMOPENJPEG_BINARY_DIR instead. The cached value is therefore the literal absolute path /bin.
3. The compatibility shim at gdcm/CMakeLists.txt:123-131 reads those variables back.

Confirmed in CMakeCache.txt after the first configure:

EXECUTABLE_OUTPUT_PATH:PATH=/bin
LIBRARY_OUTPUT_PATH:PATH=/bin

Ordering is what makes this a second-pass-only failure:

• Configure 1 — the shim runs before add_subdirectory(Utilities), so the variables are still undefined. No warning; GDCM correctly falls through to CMAKE_CURRENT_BINARY_DIR/bin. OpenJPEG then writes the /bin cache entries.
• Configure 2 — the cache is preloaded first, so if(EXECUTABLE_OUTPUT_PATH) is now true. The shim re-emits both deprecation warnings and points CMAKE_RUNTIME_OUTPUT_DIRECTORY, CMAKE_LIBRARY_OUTPUT_DIRECTORY and CMAKE_ARCHIVE_OUTPUT_DIRECTORY at /bin for all of GDCM.

Why #6557 exposed this rather than caused it

The poisoned /bin cache entry was always being written. Before #6557, Modules/ThirdParty/GDCM/src/CMakeLists.txt had:

set(EXECUTABLE_OUTPUT_PATH ${CMAKE_RUNTIME_OUTPUT_DIRECTORY})
set(LIBRARY_OUTPUT_PATH ${CMAKE_LIBRARY_OUTPUT_DIRECTORY})

Those are normal variables, which shadow the cache. So the shim still fired on every reconfigure — that is exactly the warning reported in #6551 — but it wrote the correct ITK paths, making it harmless. Removing the two lines removed the shadow, so the stale /bin value now wins. That matches the reported "the warning came back after a subsequent cmake and it caused compilation errors".

main is unaffected for an unrelated reason: a6dd845 ("ENH: Remove GDCM's OpenJPEG source") deleted the vendored OpenJPEG tree, removing ingredient #1. main vendors the same buggy v3.2.8 — it is immune by accident, not because its GDCM is fixed.

Reproduction and observed errors

cmake -G "Unix Makefiles" ../itk -DBUILD_TESTING:BOOL=OFF   # exit 0, no warnings
make                                                        # exit 0
cmake .                                                     # both deprecation warnings return
make                                                        # exit 2

The second make fails because every GDCM library tries to archive into /bin:

/usr/bin/ar: /bin/libitkgdcmjpeg16-5.4.a: Permission denied
/usr/bin/ar: /bin/libitkgdcmopenjp2-5.4.a: Permission denied
/usr/bin/ar: /bin/libitkgdcmCommon-5.4.a: Permission denied
... (gdcmuuid, gdcmcharls, gdcmsocketxx, gdcmjpeg8, gdcmjpeg12 likewise)
make: *** [Makefile:156: all] Error 2

This also explains the Windows-warnings/Linux-errors split: /bin is an unwritable absolute path on Linux, while on Windows it resolves against the current drive and merely misplaces the artifacts.

No GDCM release fixes this

Utilities/gdcmopenjpeg/CMakeLists.txt:180-182 is byte-identical, at the same line numbers, in every GDCM release:

GDCM tag	poison lines present
v3.2.8 (vendored by ITK)	yes, 180-182
v3.2.9	yes, 180-182
v3.2.10 (latest)	yes, 180-182
master	yes, 180-182

All three ingredients are intact at v3.2.10: Utilities/CMakeLists.txt:27 still sets the mismatched namespace, and CMakeLists.txt:126-133 still has the shim. So this is a live defect at GDCM's tip affecting any project that vendors GDCM's OpenJPEG and configures twice — worth reporting upstream independently of what we do here.

Proposed fix and local verification

Delete the three vestigial lines from Modules/ThirdParty/GDCM/src/gdcm/Utilities/gdcmopenjpeg/CMakeLists.txt:

-set (EXECUTABLE_OUTPUT_PATH ${OPENJPEG_BINARY_DIR}/bin CACHE PATH "Single output directory for building all executables.")
-set (LIBRARY_OUTPUT_PATH ${OPENJPEG_BINARY_DIR}/bin CACHE PATH "Single output directory for building all libraries.")
-mark_as_advanced(LIBRARY_OUTPUT_PATH EXECUTABLE_OUTPUT_PATH)

Nothing inside gdcmopenjpeg reads either variable, and GDCM's own CMAKE_*_OUTPUT_DIRECTORY fallbacks already place the targets correctly — the lines only ever served to poison the cache.

Simply fixing the typo (${${OPENJPEG_NAMESPACE}_BINARY_DIR}) is not sufficient: the cache entry would still exist, the shim would still fire on reconfigure, both warnings would still return, and all of GDCM's libraries would be redirected into OpenJPEG's bin directory.

Verified from a clean build directory (Unix Makefiles, BUILD_TESTING=OFF):

Step	Before	After
configure 1	cache gets /bin	no OUTPUT_PATH cache entries
make 1	exit 0	exit 0
cmake .	2 warnings	0 warnings
make 2	exit 2 (ar: Permission denied)	exit 0
cmake .	—	0 warnings
make 3	—	exit 0

Libraries land in <build>/lib/ as expected; nothing is written to /bin. The third pass confirms the result is idempotent rather than merely surviving one reconfigure.

Open question: this patches a vendored subtree

Modules/ThirdParty/GDCM/UpdateFromUpstream.sh imports Utilities/gdcmopenjpeg directly from malaterre/GDCM, so this deletion is a divergence that a future re-import would revert. In practice release-5.4 is unlikely to take a GDCM re-import, so an ITK-local patch seems proportionate here, but flagging it for a maintainer call.

For context on the alternatives:

• Bump the tag — does not work; see above, no release fixes this.
• Pull from InsightSoftwareConsortium/GDCM — does not help. That fork carries the identical lines, its master is 285 commits behind upstream with no unique commits, and its only ITK branch (20240315_GDCM_PATCHES_FOR_ITK) is 3 commits from 2024-03-15 on an unrelated topic (SecondaryCapture PixelSpacing), now 566 commits behind. GDCM has also never used that fork — UpdateFromUpstream.sh has only ever pointed at SourceForge (pre-2021) then malaterre/GDCM (6d35c93). Adopting the fork convention for GDCM may still be worth doing, but as its own effort, not as a vehicle for this fix.
• Upstream to malaterre/GDCM — the cleanest long-term home, and worth doing in parallel, but too slow to gate 5.4.7.

Separately, and unrelated to this bug: release-5.4 pins readonly tag="release" (a moving branch) while main pins readonly tag="v3.2.8". A floating reference on a maintenance branch may be worth a look.