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]

If downstream users are making use of the flags put into libhdf5.settings directly, I believe more work needs to occur in the library before LINK_COMP_LIBS can be safely included here. The libraries listed in LINK_COMP_LIBS are private dependencies of the library, but may or may not needed to be included in the link line, depending on how compression libraries were built. Since only LINK_LIBS was included in the file before, it may be safest to only include those libraries for now until we have better testing of library builds including filter libraries in place.

[Growl1234]

If I recall correctly, libz and libsz are included in LINK_COMP_LIBS, and I'm not sure if PR #6220 affects this behavior. On my system, after a successful compilation, the “Extra libraries” entry reads -lm;-ldl;-lz;-lsz;-laec, and no other things.

P.S. My CMake option is:

-DHDF5_BUILD_FORTRAN=ON -DHDF5_ENABLE_PARALLEL=ON -DHDF5_ENABLE_ZLIB_SUPPORT=ON -DHDF5_ENABLE_SZIP_SUPPORT=ON

with zlib and szip installed via dnf as zlib-ng-devel and libaec-devel

[jhendersonHDF]

If I recall correctly, libz and libsz are included in LINK_COMP_LIBS

Yes, they should be there in cases where they're needed but there are also some cases where they won't be needed even when zlib and szip are enabled. I suppose the worst this will cause is some over-linking though, which is better than if the flags were missing when they're needed.

[Growl1234]

So, personally I prefer keeping LINK_COMP_LIBS here.

[jhendersonHDF]

Since extract_lib_pkgconfig_info() usually gives flags in the "-l" form, I noticed that libhdf5.settings would previously have, for example, m;dl;, whereas now it would be -lm;-ldl on Linux. I'm not sure if this is a big problem overall and would also need to compare Windows and others before and after, but it's worth noting.

[Growl1234]

Unfortunately, I have not yet tested this change on Windows. I will perform further tests later today to make sure it does not interfere with the expected behavior there. Perhaps IF (NOT WIN32) still needs to be added?

[Growl1234]

I tried building HDF5 with MinGW (GCC 14.2) and CMake, with zlib and libaec installed. Here's the results showing what lib\libhdf5.settings shows:

1. Without this PR applied:
   Extra libraries: m;ws2_32;wsock32;Threads::Threads
2. With this PR applied:
   Extra libraries: -lm;-lws2_32;-lwsock32;-lz;-lsz;-laec

All lib\pkgconfig\hdf5.pc files show Libs.private: -lm -lws2_32 -lwsock32 -lz -lsz -laec, which is possibly due to how MinGW(GCC) works.

Building via CMake with Visual Studio 2022 as generator unfortunately failed on my machine. However, such warning occurred at configuration step may helps:

CMake Warning (dev) at config/HDF5Pkgconfig.cmake:84 (message):
  Cannot generate pkg-config files correctly for multi-config generators
Call Stack (most recent call first):
  src/CMakeLists.txt:1383 (extract_lib_pkgconfig_info)
This warning is for project developers.  Use -Wno-dev to suppress it.

Btw, it seems that cmake configuration of HDF5 on Windows has problem finding zlib (I have to manually set ZLIB_LIBRARY and ZLIB_INCLUDE_DIR), while it doesn't occur with libaec. The paths of both libraries are written in environment variables.

[jhendersonHDF]

1. Without this PR applied:
   Extra libraries: m;ws2_32;wsock32;Threads::Threads
2. With this PR applied:
   Extra libraries: -lm;-lws2_32;-lwsock32;-lz;-lsz;-laec

All lib\pkgconfig\hdf5.pc files show Libs.private: -lm -lws2_32 -lwsock32 -lz -lsz -laec, which is possibly due to how MinGW(GCC) works.

This looks good to me for MinGW at least. Downstream users will just need a little additional logic to check whether the flags begin with -l and do what they need to with that.

Building via CMake with Visual Studio 2022 as generator unfortunately failed on my machine. However, such warning occurred at configuration step may helps:

CMake Warning (dev) at config/HDF5Pkgconfig.cmake:84 (message):
 Cannot generate pkg-config files correctly for multi-config generators
Call Stack (most recent call first):
 src/CMakeLists.txt:1383 (extract_lib_pkgconfig_info)
This warning is for project developers.  Use -Wno-dev to suppress it.

This is new behavior I added in #6220, but I'm considering changing those warnings a little bit. They are highlighting a real issue we were silently ignoring before, but dealing with CMake generator expressions (and thus multi-config generators) in the pkg-config files is a little trickier. The real failure would have been something else; if you happen to have a log of configuring/building on Visual Studio 2022 I may be able to help figure out why it failed.

Btw, it seems that cmake configuration of HDF5 on Windows has problem finding zlib (I have to manually set ZLIB_LIBRARY and ZLIB_INCLUDE_DIR), while it doesn't occur with libaec. The paths of both libraries are written in environment variables.

I'm currently working on trying to fix many issues with using filters in HDF5; hopefully this issue will be fixed as well, but much more testing is needed on our side.

[Growl1234]

It seems I've not left a log file then. 😔 Let me try again tomorrow.
As I remember, I seemed to always get warnings related to Unicode or UTF-8, which might be associated with the VS Development Console?

[Growl1234]

Here are the logfiles:
cmake.log
make.log

Command:

cmake .. -DCMAKE_INSTALL_PREFIX="../install" -DHDF5_ENABLE_ZLIB_SUPPORT=ON -DHDF5_ENABLE_SZIP_SUPPORT=ON -DZLIB_LIBRARY="E:/testing/MSVC/zlib-1.3.2/install/lib/zd.lib" -DZLIB_INCLUDE_DIR="E:/testing/MSVC/zlib-1.3.2/install/include"
cmake --build . --target install -j 24

Error (line 41729-41731):

E:\testing\MSVC\hdf5-develop\test\tunicode.c(94,16): error C2001: newline in constant [E:\testing\MSVC\hdf5-develop\build\test\testhdf5.vcxproj]
E:\testing\MSVC\hdf5-develop\test\tunicode.c(95,5): error C2146: syntax error: missing ')' before identifier 'H5Pclose' [E:\testing\MSVC\hdf5-develop\build\test\testhdf5.vcxproj]
E:\testing\MSVC\hdf5-develop\test\tunicode.c(94,5): error C2198: 'char *h5_fixname(const char *,hid_t,char *,size_t)': too few arguments for call [E:\testing\MSVC\hdf5-develop\build\test\testhdf5.vcxproj]

[jhendersonHDF]

Thanks! We may need to specify /utf-8 for some files for MSVC, though I'd assumed that that string being a u8-prefixed literal would have made MSVC do the right thing. I'll be able to try this on Windows tomorrow and see if any adjustments should be made.

[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.