I'm trying to do a custom build of HDF5 library with cmake. More precisely, I want to build hdf5.dll with zlib support, with zlib (and msvc*) code linked info hdf5.dll statically.
From reading INSTALL_CMake.txt, I do not quite understand to which of the following aspects BUILD_SHARED_LIBS relates to:
1) Build hdf5.dll or hdf5.lib.
2) Link zlib code info hdf5 statically or dynamically.
Sorry if my question is stupid, I didn't have a chance to get experience with cmake so far
Best wishes,
Andrey Paramonov
路路路
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
BUILD_SHARED_LIBS determines how the library will be built, OFF is static and
ON is dynamic.
If you want to build a static hdf5 library, I suggest you link zlib in
statically as well. Note that the CRT will still be referenced dynamically.
(there is a way to link that in statically if you must, but is not usually
necessary).
Allen
路路路
On Thursday, May 29, 2014 07:03:25 PM 袗薪写褉械泄 袩邪褉邪屑芯薪芯胁 wrote:
Hello!
I'm trying to do a custom build of HDF5 library with cmake. More
precisely, I want to build hdf5.dll with zlib support, with zlib (and
msvc*) code linked info hdf5.dll statically.
From reading INSTALL_CMake.txt, I do not quite understand to which of
the following aspects BUILD_SHARED_LIBS relates to:
1) Build hdf5.dll or hdf5.lib.
2) Link zlib code info hdf5 statically or dynamically.
Sorry if my question is stupid, I didn't have a chance to get experience
with cmake so far
To put zlib inside the shared library, you may only need to build it
with relocation enabled, but statically, and then give this library to
CMake.
Compiling HDF5 with the CRT in static mode may not be the best
solution. You need to be absolutely sure than you don't allocate
something that the HDF5 library will free, or the other way around.
And even then, it's not the best idea ever (usual static CRT is for
full application + static libraries, nothing must be shared in any
way).
BUILD_SHARED_LIBS determines how the library will be built, OFF is static and
ON is dynamic.
If you want to build a static hdf5 library, I suggest you link zlib in
statically as well. Note that the CRT will still be referenced dynamically.
(there is a way to link that in statically if you must, but is not usually
necessary).
Allen
On Thursday, May 29, 2014 07:03:25 PM 袗薪写褉械泄 袩邪褉邪屑芯薪芯胁 wrote:
Hello!
I'm trying to do a custom build of HDF5 library with cmake. More
precisely, I want to build hdf5.dll with zlib support, with zlib (and
msvc*) code linked info hdf5.dll statically.
From reading INSTALL_CMake.txt, I do not quite understand to which of
the following aspects BUILD_SHARED_LIBS relates to:
1) Build hdf5.dll or hdf5.lib.
2) Link zlib code info hdf5 statically or dynamically.
Sorry if my question is stupid, I didn't have a chance to get experience
with cmake so far
BUILD_SHARED_LIBS determines how the library will be built, OFF is static and
ON is dynamic.
So, is it correct that if I need hdf5.dll (as opposed to *.lib) I should set BUILD_SHARED_LIBS to ON?
If you want to build a static hdf5 library, I suggest you link zlib in
statically as well. Note that the CRT will still be referenced dynamically.
(there is a way to link that in statically if you must, but is not usually
necessary).
Yes, to link zlib as well as CRT statically is what I want. My application couldn't use CRT memory manager even if it wanted to (it's not even in C), so I'm pretty safe in this regard.
Could you please share how to configure cmake to link zlib and CRT in, statically?
Best wishes,
Andrey Paramonov
路路路
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
However, if I tell cmake to include zlib support (e.g. HDF5_ALLOW_EXTERNAL_SUPPORT=SVN), CMAKE_C_FLAGS_RELEASE doesn't propagate to zlib build configuration. Also, I couldn't find out so far how to link zlib statically. CMake experts help really appreciated.
路路路
----
While experimenting with different build options, I've found out the following (minor) problems in HDF5 build files:
1) Line 20 in CMakeFilters.cmake should be changed from
option (HDF5_ALLOW_EXTERNAL_SUPPORT "Allow External Library Building (NO SVN TGZ)" "NO")
to
set (HDF5_ALLOW_EXTERNAL_SUPPORT "NO" CACHE STRING "Allow External Library Building (NO SVN TGZ)")
SET_PROPERTY(CACHE HDF5_ALLOW_EXTERNAL_SUPPORT PROPERTY STRINGS NO SVN TGZ)
because HDF5_ALLOW_EXTERNAL_SUPPORT is a tri-value, not a boolean. It fixes configuration display in cmake-gui.
2) Currently, HDF5 cannot be built under MinGW because _In_ is not defined under MinGW (H5.c, line 857). Quick workaround is to remove the "_In_"s.
It is proposed to conditionally #define _In_ to no-op if it's not #defined.
Best wishes,
Andrey Paramonov
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
