CMake error when enabling thread-safe DLLs with C++ in HDF5 1.8.13

I'm having problems building HDF5 1.8.13 as thread-safe DLLs with C++ interface. This used to work fine in previous releases.

Error message from CMake 2.8.12:
CMake Error at CMakeLists.txt:717 (message):
   **** C++ and thread-safety options are not supported ****

Steps to reproduce:
* Download HDF5 1.8.13
* Open CMake and specify Visual Studio 11 as compiler.
* Enable BUILD_SHARED_LIBS, HDF5_BUILD_CPP_LIB and HDF5_ENABLE_THREADSAFE in CMake.
* Press "Configure".

Any ideas?

Thanks in advance,
Fredrik Orderud

Hi Frederik,

The thread-safe library w/ the C++ wrappers is not a supported configuration. This is enforced when built with the autotools, where --enable-unsupported must be used if you want this combination. We've been slowly bringing CMake into line with the more official autotools build options and preventing C++/thread-safe was a part of that.

If you want to build this combination with CMake, you can edit the top-level CMakeLists.txt file. The salient bits are near line 715. Keep in mind that this is an untested and unsupported combination. The biggest potential problem is that the thread-safe locking mechanism that we use does not extend into the C++ wrappers. Addressing this is a fairly high-priority task for us. Pending funding, we'd like to get it into the library as soon as possible.

Dana

···

-----Original Message-----
From: Hdf-forum [mailto:hdf-forum-bounces@lists.hdfgroup.org] On Behalf Of
Fredrik Orderud
Sent: Thursday, May 15, 2014 4:56 AM
To: hdf-forum@lists.hdfgroup.org
Subject: [Hdf-forum] CMake error when enabling thread-safe DLLs with C++ in
HDF5 1.8.13

I'm having problems building HDF5 1.8.13 as thread-safe DLLs with C++
interface. This used to work fine in previous releases.

Error message from CMake 2.8.12:
CMake Error at CMakeLists.txt:717 (message):
   **** C++ and thread-safety options are not supported ****

Steps to reproduce:
* Download HDF5 1.8.13
* Open CMake and specify Visual Studio 11 as compiler.
* Enable BUILD_SHARED_LIBS, HDF5_BUILD_CPP_LIB and HDF5_ENABLE_THREADSAFE in
CMake.
* Press "Configure".

Any ideas?

Thanks in advance,
Fredrik Orderud

_______________________________________________
Hdf-forum is for HDF software users discussion.
Hdf-forum@lists.hdfgroup.org
http://mail.lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org

The thread-safe library w/ the C++ wrappers is not a supported configuration. This is enforced
when built with the autotools, where --enable-unsupported must be used if you want this
combination. We've been slowly bringing CMake into line with the more official autotools build
options and preventing C++/thread-safe was a part of that.

Thanks for the information Dana. I was not aware of this limitation.

If you want to build this combination with CMake, you can edit the top-level CMakeLists.txt file.
The salient bits are near line 715. Keep in mind that this is an untested and unsupported
combination.

Ok. Then I will attempt to modify CMakeLists.txt and take my chances on the unsupported configuration.

The biggest potential problem is that the thread-safe locking mechanism that we use does not
extend into the C++ wrappers. Addressing this is a fairly high-priority task for us. Pending
funding, we'd like to get it into the library as soon as possible.

This sounds a bit odd to me. There is usually no need to thread-safe a thin "wrapper"-library separately if the underlying library is already thread-safe. Are there some specific problems that I should be aware of, like e.g. shared state between C++ objects or deadlocks?

Hi Frederik,

> The biggest potential problem is that the thread-safe locking
> mechanism that we use does not extend into the C++ wrappers.
> Addressing this is a fairly high-priority task for us. Pending funding,
we'd like to get it into the library as soon as possible.

This sounds a bit odd to me. There is usually no need to thread-safe a thin
"wrapper"-library separately if the underlying library is already thread-
safe. Are there some specific problems that I should be aware of, like e.g.
shared state between C++ objects or deadlocks?

The problem is that the wrappers are not always thin. Some of the wrapper code makes multiple HDF5 calls and state could change if there were a context switch during the C++ wrapper calls.

Dana