How to switch off `HDF5_THREADS_ENABLED`?

HDF5 Library
1

Dear experts…

The current git HEAD seems to force HDF5_THREADS_ENABLED=ON if Threads_FOUND=true after find_package (Threads) even if one doesn’t want to use it.

I think this is the cause of the failure in configuring my FORTRAN project using HDF5(dev):

CMake Error at /usr/share/cmake/Modules/FindThreads.cmake:66 (message):
  FindThreads only works if either C or CXX language is enabled

The library was built with the following configuration:
FC=gfortran-14 CC=gcc-14 cmake -G "Unix Makefiles" -DCMAKE_BUILD_TYPE:STRING=Release -DBUILD_TESTING:BOOL=ON -DHDF5_BUILD_TOOLS:BOOL=ON -DHDF5_BUILD_FORTRAN=ON -DHDF5_THREADS_ENABLED=OFF ../hdf5.git/

How can I fix this issue?
How can I turn off the use of Threads?

Thanks in advance.
Kazuyoshi

2

Will reverting this PR work for you?

Fix threads and variables. by byrnHDF · Pull Request #5523 · HDFGroup/hdf5

3

@hyoklee , thanks for your response.

I must confess that I’m not sure we need to do so. I’m not an expert and therefore I don’t know the intention of the modification #5523.
I just want to use the HDF5 library as I do now for my FORTRAN project. If the threading is a must-have and I can easily enable (p?)threading with fortran on ordinary linux boxes (w/ e.g. gfortran), I’ll do it (but I’d like to know how to do it)

Thanks.
Kazuyoshi

4

Well… Googling and only adding " C CXX" after “Fortran” in the project() in the CMakeLists.txt file of our FORTRAN-only project, I managed to do cmake.

Therefore, at this moment, I don’t need to revert the PR (I don’t know what it is for).

Sorry for the noise and trouble.
Kazuyoshi

1 Like
5

Sorry again, but I now feel that it’s odd and burdensome to require C/C++ component to be included in a pure fortran-only project…

Any way to avoid this?

Thanks.
Kazuyoshi

1 Like
6

I don’t think so.

By the way, have you tried GitHub - geospace-code/h5fortran: Lightweight HDF5 polymorphic Fortran: h5write() h5read() for your project?

They build HDF5 by disabling non-essential options for Fortran and I think you can follow their approach:

cmd='/usr/local/bin/cmake;-DHDF5_ENABLE_Z_LIB_SUPPORT:BOOL=ON;-DZLIB_USE_EXTERNAL:BOOL=OFF;-DCMAKE_INSTALL_PREFIX=/Users/hyoklee/src/h5fortran/build/local;-DCMAKE_MODULE_PATH:PATH=/Users/hyoklee/src/h5fortran/cmake;-DHDF5_GENERATE_HEADERS:BOOL=false;-DHDF5_DISABLE_COMPILER_WARNINGS:BOOL=true;-DBUILD_STATIC_LIBS:BOOL=$<NOT:$<BOOL:>>;-DBUILD_SHARED_LIBS:BOOL=;-DCMAKE_BUILD_TYPE=Release;-DCMAKE_C_COMPILER=/usr/bin/cc;-DCMAKE_Fortran_COMPILER=/usr/local/bin/flang;-DHDF5_BUILD_FORTRAN:BOOL=true;-DHDF5_BUILD_CPP_LIB:BOOL=false;-DBUILD_TESTING:BOOL=false;-DHDF5_BUILD_EXAMPLES:BOOL=false;-DHDF5_BUILD_TOOLS:BOOL=true;-DHDF5_ENABLE_PARALLEL:BOOL=$<BOOL:>;-DHDF5_BUILD_PARALLEL_TOOLS:BOOL=$<BOOL:>;-GUnix Makefiles;-S;<SOURCE_DIR><SOURCE_SUBDIR>;-B;<BINARY_DIR>'
7

Hi @furutaka.kazuyoshi,

The short answer:

This isn’t strictly necessary for your use case and should probably be fixed in the current HDF5 development branch. A temporary workaround would be to edit the CMake configuration file installed by HDF5 (under cmake/hdf5-config.cmake on Linux) and change the value of the line

set (${HDF5_PACKAGE_NAME}_THREADS_ENABLED ON)

to

set (${HDF5_PACKAGE_NAME}_THREADS_ENABLED OFF)

Note that HDF5_THREADS_ENABLED is not something that is user-controlled at the moment, so passing this as an option likely doesn’t have an effect.

The long answer:

Threading support should only be enabled and required when actually required by HDF5 due to some feature being built in. But the logic in the CMake configuration file installed by HDF5 currently looks for threading functionality just based on whether threading functionality was initially found when HDF5 was configured. In your case, threading functionality is (presumably) not needed, and so the eventual find_package(Threads ...) call in that configuration file shouldn’t be needed. But if the HDF5 you were building against had any feature enabled which does require threading functionality, you’d have the same issue. Based on Policy: ban `enable_language()` from within `find_package()` (#26751) · Issues · CMake / CMake · GitLab, it seems it would be best if we just check for the C language being enabled when required and failing the configure step if it’s not.

8

You can exclude C++, but not C. The C component is the core library which handles all basic HDF5 functionality. It can never be disabled.

The C++ and Fortran API’s are wrappers around the core C library. C++ is disabled with the CMake option HDF5_BUILD_CPP_LIB=OFF. Actually, it should already be off by default. Please see “CMake Option Defaults for HDF5” in the HDF5 CMake install documentation. Current location:

9

Dear experts, thanks for your valuable reply!

Well, it’s true that the HDF5 library is written in C and that in order to build it C is essential.
But I think it’s burdensome to require C for a pure-FORTRAN project which uses HDF5 library even after the library with FORTRAN wrapper was built. (I agree that in that case there should be a C compiler and I CAN add C to the project(), but…)

I can use HDF5-1.14.6 with just project(... LANGUAGES Fortran).

Kazuyoshi

10

I am not sure what you mean here by “require C”. If you want to assemble a package with minimal parts, then I THINK you can pre-build the C and fortran libraries, then discard the C compiler and all the HDF5 source code. You are left with HDF5 C and fortran runtime libraries and installed headers, and also certain other lower level support libraries such as zlib; C and fortran system runtimes; and maybe filter plugins. At the API level, the HDF5 C library should be invisible to any application programs that are using only the pure fortran interface.

I never thought of the HDF5-C library lurking in the background, as “burdensome”. :wink:

11

Thanks for your comment, @dave.allured

Sorry for my poor language.

What I mean is that once the HDF5-C library with FORTRAN wrapper was built, we don’t need TO REQUIRE C toolkit (compilers etc.) by doing project(something LANGUAGES C Fortran) to build a pure-FORTRAN project depending on the library.

Kazuyoshi

12

Dear @jhenderson , thanks for your help!

This works like a charm!

Since my goal is to provide a portable CMakeLists.txt for a FORTRAN project which partly depends on the HDF5 library, and I don’t want our user to ask to tweak the library itself (would rather let them use pristine precompiled/ready-made binary), I’d be happy if the default value of HDF5_THREADS_ENABLED be changed in the future releases.

Thanks!
Kazuyoshi

13

Dear @hyoklee ,

Thanks for the info.

Although the project you mentioned is very interesting to me, as I wrote in another reply as the following, I would rather (let our users) use the ready-made library (either as provided by the HDF group (thanks! ありがとうございます) or packaged by e.g. linux distributions): at present, there seems to be a bug in allocatable character arrays in gfortran ver.15, and I have to compile HDF5 library with other FORTRAN compilers (gfortran-14 or ifx) by myself…

Kazuyoshi

14

Hi…

Even in the latest release version (2.0.0) built w/ HDF5_ENABLE_THREADSAFE:BOOL=OFF, ${HDF5_PACKAGE_NAME}_PROVIDES_THREADS is set to ON?

Kazuyoshi