Fixes #6171

[Growl1234]

Generate "Extra libraries" in libhdf5.settings using a new variable LINK_LIBS_SETTINGS rather than LINK_LIBS.

Fixes #6171.

---

Important

Generate "Extra libraries" in libhdf5.settings using LINK_LIBS_SETTINGS with formatted linker flags in CMakeLists.txt.

• Behavior:
  • Generate "Extra libraries" in libhdf5.settings using LINK_LIBS_SETTINGS instead of LINK_LIBS.
  • Introduces _hdf5_resolve_lib_to_flag function in CMakeLists.txt to format linker flags.
• CMake:
  • Adds LINK_LIBS_SETTINGS variable in CMakeLists.txt to store formatted linker flags.
  • Converts semicolon-separated list to space-separated string for LINK_LIBS_SETTINGS.
• Settings:
  • Updates src/libhdf5.settings.in to use @LINK_LIBS_SETTINGS@ for "Extra libraries".

^{This description was created by for 2c69ea3. You can customize this summary. It will automatically update as commits are pushed.}

[jhendersonHDF]

@Growl1234 You may want to look at #6220 as I believe the new function there can cover most of what you're doing here without needing to have special exceptions for any particular CMake target such as Threads::Threads (that target includes CMAKE_THREAD_LIBS_INIT in the INTERFACE_LINK_LIBRARIES property picked up by the extract_lib_pkgconfig_info() function). It's also worth noting that I removed the setting of OUTPUT_NAME for zlib and libaec as that's no longer necessary.

[Growl1234]

@Growl1234 You may want to look at #6220 as I believe the new function there can cover most of what you're doing here without needing to have special exceptions for any particular CMake target such as Threads::Threads (that target includes CMAKE_THREAD_LIBS_INIT in the INTERFACE_LINK_LIBRARIES property picked up by the extract_lib_pkgconfig_info() function). It's also worth noting that I removed the setting of OUTPUT_NAME for zlib and libaec as that's no longer necessary.

Thanks for your dedication, and it's great to see the specified OUTPUT_NAME is no longer needed!

[Growl1234]

This PR is updated based on #6220 which has not been merged to the develop branch yet, and all checks should pass after #6220 is merged.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[jhendersonHDF]

@Growl1234 With #6220 merged you'll want to rebase on/merge in develop now.

[jhendersonHDF]

@Growl1234 Due to the check I needed to put at https://github.com/HDFGroup/hdf5/blob/develop/config/HDF5Pkgconfig.cmake#L94, extract_lib_pkgconfig_info() is currently problematic to use on Windows and the file comes out like below.

         SUMMARY OF THE HDF5 CONFIGURATION
        =================================

General Information:
-------------------
                   HDF5 Version: 2.2.0
                  Configured on: 2026-02-24
                  Configured by: Visual Studio 17 2022
                    Host system: Windows-10.0.22621
              Uname information: Windows
                       Byte sex: little-endian
             Installation point: C:/Program Files/HDF_Group/HDF5/2.2.0

Compiling Options:
------------------
                     Build Mode: $<CONFIG>
              Debugging Symbols: OFF
                        Asserts: OFF
                      Profiling: OFF
             Optimization Level: OFF

Linking Options:
----------------
                      Libraries: 
  Statically Linked Executables: OFF
                        LDFLAGS: /machine:x64
                     H5_LDFLAGS: 
                     AM_LDFLAGS: 
                Extra libraries: 
                       Archiver: C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.44.35207/bin/Hostx64/x64/lib.exe
                       AR_FLAGS:
                         Ranlib: :

Languages:
----------
                              C: YES
                     C Compiler: C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.44.35207/bin/Hostx64/x64/cl.exe 19.44.35215.0
                       CPPFLAGS: 
                    H5_CPPFLAGS: 
                    AM_CPPFLAGS: 
                         CFLAGS:  -std:c11 /DWIN32 /D_WINDOWS -wd5105 
                      H5_CFLAGS: /W3;/wd4100;/wd4706;/wd4127
                      AM_CFLAGS: 
               Shared C Library: YES
               Static C Library: YES

                        Fortran: OFF
               Fortran Compiler:  
                  Fortran Flags:  
               H5 Fortran Flags: 
               AM Fortran Flags: 
         Shared Fortran Library: YES
         Static Fortran Library: YES
               Module Directory: C:/Users/_user_/hdf5/build/mod

                            C++: OFF
                   C++ Compiler:  
                      C++ Flags:  
                   H5 C++ Flags: 
                   AM C++ Flags: 
             Shared C++ Library: YES
             Static C++ Library: YES

                           JAVA: OFF
                  JAVA Compiler:  

Features:
---------
                     Parallel HDF5: OFF
  Parallel Filtered Dataset Writes: 
                Large Parallel I/O: 
                High-level library: ON
Dimension scales w/ new references: 
                  Build HDF5 Tests: ON
                  Build HDF5 Tools: ON
                           Threads: ON
                      Threadsafety: OFF
                       Concurrency: OFF
               Default API mapping: v200
    With deprecated public symbols: ON
            I/O filters (external): 
                  _Float16 support: OFF
                     Map (H5M) API: OFF
                        Direct VFD: OFF
                        Mirror VFD: OFF
                     Subfiling VFD: OFF
                (Read-Only) S3 VFD: OFF
              (Read-Only) HDFS VFD: OFF
    Packages w/ extra debug output: 
                       API Tracing: OFF
              Using memory checker: OFF
                  Use file locking: best-effort
         Strict File Format Checks: OFF
      Optimization Instrumentation: 

Editing the function a bit to only give warning, the libraries line comes out as

Extra libraries: -lzlib-static

which is probably a little odd for Windows. I think it makes sense to just remove -l and keep only the library names as before and let downstream people decide how to link those in if needed.

But we also still have to deal with the issue that with multi-config generators the build type isn't known until build time, so we can't guarantee that we're returning the correct libraries/flags on Windows since we don't know which build configuration library to use yet. You can also see above that $<CONFIG> appears as the build type because it hasn't been determined yet when libhdf5.settings is generated during configure time. I think fixing this fully will require creating libhdf5.settings at build time. Omitting the extra libraries line might be acceptable on Windows for the time being though.

[Growl1234]

With this commit the lib/libhdf5.settings now shows on my computer (I deal with my compilation issue with manually adding /utf-8 in flags):

Extra libraries: zlibstatic;szip;aec

while lib/pkgconfig/hdf5.pc still shows:

Libs.private: -lzlibstatic -lszip -laec

Further tests maybe needed.

Moreover, ws2_32 and wsock32 are losing, and I’m not sure whether this could have any negative impact.

[jhendersonHDF]

Thanks for your work @Growl1234. I'll do a bit more testing but I think the changes generally look good.

Moreover, ws2_32 and wsock32 are losing, and I’m not sure whether this could have any negative impact.

From what I can tell, these libraries only get added to HDF5_REQUIRED_LIBRARIES, which is only linked to a program for generating testing files for the tools. In several places wsock32.lib and ws2_32.lib are linked directly, but this is only linked to testing programs/libraries, so I think this is OK.

[Growl1234]

I’m wondering whether it would be possible to move the generation of .pc and related files to the installation stage (for example, using install(CODE ... )), in order to fully address the multi-config generator issue. A potential downside, however, is that it might require substantial modifications to files such as HDF5PkgConfig.cmake. (Admittedly, this may go beyond the scope of the current PR.)

Or alternatively, we could generate the corresponding files for each build type during the configuration or build stage, and then let the generator select the appropriate one at installation time.

[jhendersonHDF]

I’m wondering whether it would be possible to move the generation of .pc and related files to the installation stage (for example, using install(CODE ... )), in order to fully address the multi-config generator issue. A potential downside, however, is that it might require substantial modifications to files such as HDF5PkgConfig.cmake. (Admittedly, this may go beyond the scope of the current PR.)

I see this as being the only way to go in the future since we also have to deal with CMake generator expressions, but I also agree that that's far outside the scope of this PR. It's something I'd like to do though.

[Growl1234]

Hi @jhendersonHDF

I wonder if you might be interested in taking a look at this, which shows a possible approach to handling multi-configuration generators in a better way. It involves relatively substantial modifications to HDF5PkgConfig.cmake, but it has not been thoroughly tested and I cannot be certain that the behavior is entirely correct and safe. Nevertheless, I believe it may help address the issues related to multi-configuration generators to some extent.

[jhendersonHDF]

I wonder if you might be interested in taking a look at this, which shows a possible approach to handling multi-configuration generators in a better way.

It will likely be a while before I can get around to looking at your changes, but it looks like it's moving in the right direction at least. We will probably want to make use of https://cmake.org/cmake/help/latest/command/file.html#generate in order to process generator expressions in the file, which would include the MSVC build configuration.

[Growl1234]

We will probably want to make use of https://cmake.org/cmake/help/latest/command/file.html#generate in order to process generator expressions in the file, which would include the MSVC build configuration.

I really like the idea of using the file(GENERATE ...) function! Though I think that this change would likely involve a somewhat broader scope.