netCDFTargets.cmake and pkgconfig netcdf.pc have wrong hdf5 libraries

[Chrismarsh]

If netcdf-c is built as a shared library with cmake, the installed netCDFTargets.cmake and pkconfig netcdf.pc list hdf5_hl-shared and hdf5-shared as dependent libraries. These libraries do not exist and are (seemingly) the names of the hdf5 target: hdf5::hdf5-shared. E.g.,

Libs.private: -lhdf5_hl-shared -lhdf5-shared -lm -lz -lzstd -lbz2 -lcurl -lpnetcdf -lxml2

This ends up being problematic as consumer libraries (vtk9 in my case) tries to use these libraries and fails to find them.

I see in my test that

find_package(HDF5 COMPONENTS C HL REQUIRED)

message(STATUS "${HDF5_LIBRARIES}")
message(STATUS "${HDF5_C_LIBRARIES}")

Produces: hdf5-shared as output. Given that is how it is used here https://github.com/Unidata/netcdf-c/blob/v4.9.2/liblib/CMakeLists.txt#L119 it's not surprising this shows up as an issue.

I see references to this problem here https://bugs.gentoo.org/833943 and https://github.com/Unidata/netcdf-c/issues/1444#issuecomment-621027824

Ammending the filter here https://github.com/Unidata/netcdf-c/blob/main/CMakeLists.txt#L1595 fixes the pkgconfig, and I think a similar here https://github.com/Unidata/netcdf-c/blob/v4.9.2/liblib/CMakeLists.txt#L121 would filter it out for the cmake (testing now).

I'm wondering if there was other progress on this issue or if I should submit this as a fix as a PR?

[WardF]

I'm taking a closer look at this, a PR would be a great, I'm failing to replicate this issue but it clearly exists, so I'm trying to narrow down the circumstances in which it occurs.