You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
When building with the bundled HDF5 - its targets are exported (when they shouldn't be) #5755
If I build ITK with the built-in, rather than a system, HDF5, then cmake --install it - the resulting config file(s) contain HDF5 targets. It can easily cause a build of another project, which find_package()'s both ITK and HDF5 independently of ITK, to have clashes. I doubt this is intentional (although - correct me if I'm wrong).
This might also be happening with other bundled libraries. I haven't checked.
Just this morning a PR was merged into ITK which add a namespace to all the targets including HDF5. You can see the PR here: #5721
This is a large change to the ITK CMake code, and will likely have folow up changes.
This changes should help to address conflicts in the CMake interface libraries. Mostly of the integrated 3rd partly libraries have their symbols mangled to prevent conflict with system libraries.
Please test the current main and let us know if it addresses your problem.
@blowekamp : First, thanks for the prompt reply. That PR is rather huge; and I am not familiar with the ITK module system, so it's a bit difficult to parse. But your point is taken about the prepending of an ITK namespace - I just hope that applies to bundled libraries.
TBH, I doubt that HDF5 targets should be exposed at all as ITK targets. But my main concern is actually with the 5.x versions. Is there a chance that something could be done about clashing targets in the 5.x line? Perhaps on the release-5.4 branch or somewhere similar?
changed the title [-]When building with the bundled HDF5 - its targets are exported[/-][+]When building with the bundled HDF5 - its targets are exported (when they shouldn't)[/+]on Feb 5, 2026
changed the title [-]When building with the bundled HDF5 - its targets are exported (when they shouldn't)[/-][+]When building with the bundled HDF5 - its targets are exported (when they shouldn't be)[/+]on Feb 5, 2026
Activity
github-actions commentedon Feb 2, 2026
Thank you for contributing an issue! 🙏
Welcome to the ITK community! 🤗👋☀️
We are glad you are here and appreciate your contribution. Please keep in mind our community participation guidelines. 📜
Also, please check existing open issues and consider discussion on the ITK Discourse. 📖
This is an automatic message. Allow for time for the ITK community to be able to read the issue and comment on it.
blowekamp commentedon Feb 2, 2026
Hello,
Just this morning a PR was merged into ITK which add a namespace to all the targets including HDF5. You can see the PR here:
#5721
This is a large change to the ITK CMake code, and will likely have folow up changes.
This changes should help to address conflicts in the CMake interface libraries. Mostly of the integrated 3rd partly libraries have their symbols mangled to prevent conflict with system libraries.
Please test the current main and let us know if it addresses your problem.
eyalroz commentedon Feb 2, 2026
@blowekamp : First, thanks for the prompt reply. That PR is rather huge; and I am not familiar with the ITK module system, so it's a bit difficult to parse. But your point is taken about the prepending of an
ITKnamespace - I just hope that applies to bundled libraries.TBH, I doubt that HDF5 targets should be exposed at all as ITK targets. But my main concern is actually with the 5.x versions. Is there a chance that something could be done about clashing targets in the 5.x line? Perhaps on the release-5.4 branch or somewhere similar?
[-]When building with the bundled HDF5 - its targets are exported[/-][+]When building with the bundled HDF5 - its targets are exported (when they shouldn't)[/+][-]When building with the bundled HDF5 - its targets are exported (when they shouldn't)[/-][+]When building with the bundled HDF5 - its targets are exported (when they shouldn't be)[/+]hjmjohnson commentedon Apr 15, 2026
Related Discourse discussions: