Just updated to 1.8.10 by building HDf5 myself with VS2010 as dynamic
libraries. When compiling my own application against this new build i
am getting the following errors:
libDREAM3DLib.lib(StatsData.obj) : error LNK2001: unresolved external symbol
H5T_NATIVE_UINT16_g [C:\Users\mjackson\Workspace\DREAM3D\x64\Tools\H5VoxelToVtk
.vcxproj]
When i switch back to my 1.8.9 build I do not get these errors. is
there something that needs to get updated in projects that link
against hdf5 1.8.10 versus 1.8.9?
Are you using CMake to create the hdf5 library? There is an issue with a
definition that needs to be solved for the next release (the pre-built binaries
have this define in the H5pubconf.h).
Add #define H5_BUILT_AS_DYNAMIC_LIB 1
in your H5pubconf.h file after building HDF5.
Allen
···
On Tuesday, November 20, 2012 10:57:01 AM Michael Jackson wrote:
Just updated to 1.8.10 by building HDf5 myself with VS2010 as dynamic
libraries. When compiling my own application against this new build i
am getting the following errors:
libDREAM3DLib.lib(StatsData.obj) : error LNK2001: unresolved external
symbol H5T_NATIVE_UINT16_g
[C:\Users\mjackson\Workspace\DREAM3D\x64\Tools\H5VoxelToVtk .vcxproj]
When i switch back to my 1.8.9 build I do not get these errors. is
there something that needs to get updated in projects that link
against hdf5 1.8.10 versus 1.8.9?
thanks for any help
_________________________________________________________
Mike Jackson mike.jackson@bluequartz.net
BlueQuartz Software www.bluequartz.net
Principal Software Engineer Dayton, Ohio
Hmm
Looking at the H5pubconf.h for the 1.8.9 and 1.8.10 builds it would seem that there were some merge issues maybe? Otherwise why was that definition removed? Not that I run the tests much (I assume if HDF5 is release then all the tests are passing but how would any of the tests run if nothing to can correctly? Odd. Let me take a look. Can we get this into the first patch release if I figure out what went wrong?
Are you using CMake to create the hdf5 library? There is an issue with a
definition that needs to be solved for the next release (the pre-built binaries
have this define in the H5pubconf.h).
Add #define H5_BUILT_AS_DYNAMIC_LIB 1
in your H5pubconf.h file after building HDF5.
Allen
On Tuesday, November 20, 2012 10:57:01 AM Michael Jackson wrote:
Just updated to 1.8.10 by building HDf5 myself with VS2010 as dynamic
libraries. When compiling my own application against this new build i
am getting the following errors:
libDREAM3DLib.lib(StatsData.obj) : error LNK2001: unresolved external
symbol H5T_NATIVE_UINT16_g
[C:\Users\mjackson\Workspace\DREAM3D\x64\Tools\H5VoxelToVtk .vcxproj]
When i switch back to my 1.8.9 build I do not get these errors. is
there something that needs to get updated in projects that link
against hdf5 1.8.10 versus 1.8.9?
thanks for any help
_________________________________________________________
Mike Jackson mike.jackson@bluequartz.net
BlueQuartz Software www.bluequartz.net
Principal Software Engineer Dayton, Ohio
The problem was that I attempted to allow multiple installs (debug/release,
static/dynamic) of hdf5. Everything works great with cmake, because the value
is set by the FIND_PACKAGE command. However, I failed to account for the non-
cmake process. I wanted to eliminate the duplicate include folders that would
result from multiple installs.
What to do with that definition is the issue!
Allen
···
On Tuesday, November 20, 2012 02:04:21 PM Michael Jackson wrote:
Hmm
Looking at the H5pubconf.h for the 1.8.9 and 1.8.10 builds it would seem
that there were some merge issues maybe? Otherwise why was that definition
removed? Not that I run the tests much (I assume if HDF5 is release then
all the tests are passing but how would any of the tests run if nothing to
can correctly? Odd. Let me take a look. Can we get this into the first
patch release if I figure out what went wrong?
___________________________________________________________
Mike Jackson Principal Software Engineer
BlueQuartz Software Dayton, Ohio mike.jackson@bluequartz.netwww.bluequartz.net
On Nov 20, 2012, at 1:56 PM, Allen D Byrne wrote:
> Mike,
>
> Are you using CMake to create the hdf5 library? There is an issue with a
> definition that needs to be solved for the next release (the pre-built
> binaries have this define in the H5pubconf.h).
> Add
>
> #define H5_BUILT_AS_DYNAMIC_LIB 1
>
> in your H5pubconf.h file after building HDF5.
>
> Allen
>
> On Tuesday, November 20, 2012 10:57:01 AM Michael Jackson wrote:
>> Just updated to 1.8.10 by building HDf5 myself with VS2010 as dynamic
>> libraries. When compiling my own application against this new build i
>>
>> am getting the following errors:
>> libDREAM3DLib.lib(StatsData.obj) : error LNK2001: unresolved external
>>
>> symbol H5T_NATIVE_UINT16_g
>> [C:\Users\mjackson\Workspace\DREAM3D\x64\Tools\H5VoxelToVtk .vcxproj]
>>
>> When i switch back to my 1.8.9 build I do not get these errors. is
>> there something that needs to get updated in projects that link
>> against hdf5 1.8.10 versus 1.8.9?
>>
>> thanks for any help
>> _________________________________________________________
>> Mike Jackson mike.jackson@bluequartz.net
>> BlueQuartz Software www.bluequartz.net
>> Principal Software Engineer Dayton, Ohio
>>
>> _______________________________________________
>> Hdf-forum is for HDF software users discussion.
>> Hdf-forum@hdfgroup.org
>> http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org
Inside of the Top level CMakeLists.txt file I have this now.
OPTION (BUILD_SHARED_LIBS "Build Shared Libraries" OFF)
set(H5_BUILT_AS_DYNAMIC_LIB 0)
set(H5_BUILT_AS_STATIC_LIB 1)
SET (LIB_TYPE STATIC)
SET (H5_ENABLE_SHARED_LIB NO)
SET (H5_ENABLE_STATIC_LIB NO)
IF (BUILD_SHARED_LIBS)
SET (LIB_TYPE SHARED)
ADD_DEFINITIONS (-DH5_BUILT_AS_DYNAMIC_LIB)
set(H5_BUILT_AS_DYNAMIC_LIB 1)
set(H5_BUILT_AS_STATIC_LIB 0)
SET (H5_ENABLE_SHARED_LIB YES)
ELSE (BUILD_SHARED_LIBS)
ADD_DEFINITIONS (-DH5_BUILT_AS_STATIC_LIB)
set(H5_BUILT_AS_DYNAMIC_LIB 0)
set(H5_BUILT_AS_STATIC_LIB 1)
SET (H5_ENABLE_STATIC_LIB YES)
IF (NOT WIN32)
# should this be a user setting : Everyone uses it anyway ?
ADD_DEFINITIONS (-DPIC)
ENDIF (NOT WIN32)
ENDIF (BUILD_SHARED_LIBS)
Then in config/cmake/H5pubconf.h.in I added the following:
/* Defined if HDF5 was built with CMake AND build as a shared library */ #cmakedefine H5_BUILT_AS_DYNAMIC_LIB @H5_BUILT_AS_DYNAMIC_LIB@
/* Defined if HDF5 was built with CMake AND build as a static library */ #cmakedefine H5_BUILT_AS_STATIC_LIB @H5_BUILT_AS_STATIC_LIB@
Which now allows everything to work. I am still confused why the change was needed for Debug/Release? Ironically enough I'm the original person to put the H5_BUILT_AS_DYNAMIC_LIB flag in the header file because when on windows and using CMake in another project that includes HDF5 I needed to be able to better figure out how the libraries were built so I could make decisions on what needs to be copied into my deployment package.
The problem was that I attempted to allow multiple installs (debug/release,
static/dynamic) of hdf5. Everything works great with cmake, because the value
is set by the FIND_PACKAGE command. However, I failed to account for the non-
cmake process. I wanted to eliminate the duplicate include folders that would
result from multiple installs.
What to do with that definition is the issue!
Allen
On Tuesday, November 20, 2012 02:04:21 PM Michael Jackson wrote:
Hmm
Looking at the H5pubconf.h for the 1.8.9 and 1.8.10 builds it would seem
that there were some merge issues maybe? Otherwise why was that definition
removed? Not that I run the tests much (I assume if HDF5 is release then
all the tests are passing but how would any of the tests run if nothing to
can correctly? Odd. Let me take a look. Can we get this into the first
patch release if I figure out what went wrong?
___________________________________________________________
Mike Jackson Principal Software Engineer
BlueQuartz Software Dayton, Ohio mike.jackson@bluequartz.netwww.bluequartz.net
On Nov 20, 2012, at 1:56 PM, Allen D Byrne wrote:
Mike,
Are you using CMake to create the hdf5 library? There is an issue with a
definition that needs to be solved for the next release (the pre-built
binaries have this define in the H5pubconf.h).
Add
#define H5_BUILT_AS_DYNAMIC_LIB 1
in your H5pubconf.h file after building HDF5.
Allen
On Tuesday, November 20, 2012 10:57:01 AM Michael Jackson wrote:
Just updated to 1.8.10 by building HDf5 myself with VS2010 as dynamic
libraries. When compiling my own application against this new build i
am getting the following errors:
libDREAM3DLib.lib(StatsData.obj) : error LNK2001: unresolved external
symbol H5T_NATIVE_UINT16_g
[C:\Users\mjackson\Workspace\DREAM3D\x64\Tools\H5VoxelToVtk .vcxproj]
When i switch back to my 1.8.9 build I do not get these errors. is
there something that needs to get updated in projects that link
against hdf5 1.8.10 versus 1.8.9?
thanks for any help
_________________________________________________________
Mike Jackson mike.jackson@bluequartz.net
BlueQuartz Software www.bluequartz.net
Principal Software Engineer Dayton, Ohio
Sorry didn't mean to confuse - debug/release - I was thinking globally about
the issue, obviously these defines have nothing to do with debug/release other
then creating another set of folders. The find_package would happen after hdf5
is installed and using cmake to read the hdf5 cmake configuration.
I was hoping to remove the build specific defines in H5pubconf.h to somewhere
else, because these defines are the only difference between static/dynamic
installs. Libraries are named unique enough.
Of course thinking about it now, there are other optional components in
H5pubconf.h! (szip/zlib/parallel...)
Allen
···
On Tuesday, November 20, 2012 03:27:16 PM Michael Jackson wrote:
Which "FIND_PACKAGE" sets that variable?
Inside of the Top level CMakeLists.txt file I have this now.
OPTION (BUILD_SHARED_LIBS "Build Shared Libraries" OFF)
set(H5_BUILT_AS_DYNAMIC_LIB 0)
set(H5_BUILT_AS_STATIC_LIB 1)
SET (LIB_TYPE STATIC)
SET (H5_ENABLE_SHARED_LIB NO)
SET (H5_ENABLE_STATIC_LIB NO)
IF (BUILD_SHARED_LIBS)
SET (LIB_TYPE SHARED)
ADD_DEFINITIONS (-DH5_BUILT_AS_DYNAMIC_LIB)
set(H5_BUILT_AS_DYNAMIC_LIB 1)
set(H5_BUILT_AS_STATIC_LIB 0)
SET (H5_ENABLE_SHARED_LIB YES)
ELSE (BUILD_SHARED_LIBS)
ADD_DEFINITIONS (-DH5_BUILT_AS_STATIC_LIB)
set(H5_BUILT_AS_DYNAMIC_LIB 0)
set(H5_BUILT_AS_STATIC_LIB 1)
SET (H5_ENABLE_STATIC_LIB YES)
IF (NOT WIN32)
# should this be a user setting : Everyone uses it anyway ?
ADD_DEFINITIONS (-DPIC)
ENDIF (NOT WIN32)
ENDIF (BUILD_SHARED_LIBS)
Then in config/cmake/H5pubconf.h.in I added the following:
/* Defined if HDF5 was built with CMake AND build as a shared library */ #cmakedefine H5_BUILT_AS_DYNAMIC_LIB @H5_BUILT_AS_DYNAMIC_LIB@
/* Defined if HDF5 was built with CMake AND build as a static library */ #cmakedefine H5_BUILT_AS_STATIC_LIB @H5_BUILT_AS_STATIC_LIB@
Which now allows everything to work. I am still confused why the change was
needed for Debug/Release? Ironically enough I'm the original person to put
the H5_BUILT_AS_DYNAMIC_LIB flag in the header file because when on windows
and using CMake in another project that includes HDF5 I needed to be able
to better figure out how the libraries were built so I could make decisions
on what needs to be copied into my deployment package.
On Nov 20, 2012, at 2:36 PM, Allen D Byrne wrote:
> The problem was that I attempted to allow multiple installs
> (debug/release,
> static/dynamic) of hdf5. Everything works great with cmake, because the
> value is set by the FIND_PACKAGE command. However, I failed to account
> for the non- cmake process. I wanted to eliminate the duplicate include
> folders that would result from multiple installs.
>
> What to do with that definition is the issue!
>
> Allen
>
> On Tuesday, November 20, 2012 02:04:21 PM Michael Jackson wrote:
>> Hmm
>>
>> Looking at the H5pubconf.h for the 1.8.9 and 1.8.10 builds it would seem
>>
>> that there were some merge issues maybe? Otherwise why was that
>> definition
>> removed? Not that I run the tests much (I assume if HDF5 is release then
>> all the tests are passing but how would any of the tests run if nothing
>> to
>> can correctly? Odd. Let me take a look. Can we get this into the first
>> patch release if I figure out what went wrong?
>> ___________________________________________________________
>> Mike Jackson Principal Software Engineer
>> BlueQuartz Software Dayton, Ohio
>> mike.jackson@bluequartz.netwww.bluequartz.net
>>
>> On Nov 20, 2012, at 1:56 PM, Allen D Byrne wrote:
>>> Mike,
>>>
>>> Are you using CMake to create the hdf5 library? There is an issue with a
>>> definition that needs to be solved for the next release (the pre-built
>>> binaries have this define in the H5pubconf.h).
>>> Add
>>>
>>> #define H5_BUILT_AS_DYNAMIC_LIB 1
>>>
>>> in your H5pubconf.h file after building HDF5.
>>>
>>> Allen
Relying on someone else NOT to rename the libraries because they monkey around with the CMake files probably isn't a good option either. If you ask "how are libraries named on Windows" you will get at least 2 different answers (most likely more). With mingw they are .dylib, with msvc they should be .dll. But where are the "Runtime" libraries installed versus the link time libraries? some install them into lib some install them into bin. Some install in both places. I got tired of trying to out-think the other person and just added those symbols to the header. I have my own "FindHDF5.cmake" that looks specifically for those symbols during my project's configure process then can make smarter decisions based on what it finds.
Still confused on the "... creating other folders." What other folders are getting created?
I don't have a problem with moving the build specific defines somewhere out of H5pubconf.h. Just let me know where you want them. I guess I'll add the necessary version checking code to my own project to know that if we are HDF5 1.8.10 or less I look in a certain header otherwise look in another place. Having that define in there solves a lot of deployment problems for windows and to some extent OS X.
Sorry didn't mean to confuse - debug/release - I was thinking globally about
the issue, obviously these defines have nothing to do with debug/release other
then creating another set of folders. The find_package would happen after hdf5
is installed and using cmake to read the hdf5 cmake configuration.
I was hoping to remove the build specific defines in H5pubconf.h to somewhere
else, because these defines are the only difference between static/dynamic
installs. Libraries are named unique enough.
Of course thinking about it now, there are other optional components in
H5pubconf.h! (szip/zlib/parallel...)
Allen
On Tuesday, November 20, 2012 03:27:16 PM Michael Jackson wrote:
Which "FIND_PACKAGE" sets that variable?
Inside of the Top level CMakeLists.txt file I have this now.
OPTION (BUILD_SHARED_LIBS "Build Shared Libraries" OFF)
set(H5_BUILT_AS_DYNAMIC_LIB 0)
set(H5_BUILT_AS_STATIC_LIB 1)
SET (LIB_TYPE STATIC)
SET (H5_ENABLE_SHARED_LIB NO)
SET (H5_ENABLE_STATIC_LIB NO)
IF (BUILD_SHARED_LIBS)
SET (LIB_TYPE SHARED)
ADD_DEFINITIONS (-DH5_BUILT_AS_DYNAMIC_LIB)
set(H5_BUILT_AS_DYNAMIC_LIB 1)
set(H5_BUILT_AS_STATIC_LIB 0)
SET (H5_ENABLE_SHARED_LIB YES)
ELSE (BUILD_SHARED_LIBS)
ADD_DEFINITIONS (-DH5_BUILT_AS_STATIC_LIB)
set(H5_BUILT_AS_DYNAMIC_LIB 0)
set(H5_BUILT_AS_STATIC_LIB 1)
SET (H5_ENABLE_STATIC_LIB YES)
IF (NOT WIN32)
# should this be a user setting : Everyone uses it anyway ?
ADD_DEFINITIONS (-DPIC)
ENDIF (NOT WIN32)
ENDIF (BUILD_SHARED_LIBS)
Then in config/cmake/H5pubconf.h.in I added the following:
/* Defined if HDF5 was built with CMake AND build as a shared library */ #cmakedefine H5_BUILT_AS_DYNAMIC_LIB @H5_BUILT_AS_DYNAMIC_LIB@
/* Defined if HDF5 was built with CMake AND build as a static library */ #cmakedefine H5_BUILT_AS_STATIC_LIB @H5_BUILT_AS_STATIC_LIB@
Which now allows everything to work. I am still confused why the change was
needed for Debug/Release? Ironically enough I'm the original person to put
the H5_BUILT_AS_DYNAMIC_LIB flag in the header file because when on windows
and using CMake in another project that includes HDF5 I needed to be able
to better figure out how the libraries were built so I could make decisions
on what needs to be copied into my deployment package.
The problem was that I attempted to allow multiple installs
(debug/release,
static/dynamic) of hdf5. Everything works great with cmake, because the
value is set by the FIND_PACKAGE command. However, I failed to account
for the non- cmake process. I wanted to eliminate the duplicate include
folders that would result from multiple installs.
What to do with that definition is the issue!
Allen
On Tuesday, November 20, 2012 02:04:21 PM Michael Jackson wrote:
Hmm
Looking at the H5pubconf.h for the 1.8.9 and 1.8.10 builds it would seem
that there were some merge issues maybe? Otherwise why was that
definition
removed? Not that I run the tests much (I assume if HDF5 is release then
all the tests are passing but how would any of the tests run if nothing
to
can correctly? Odd. Let me take a look. Can we get this into the first
patch release if I figure out what went wrong?
___________________________________________________________
Mike Jackson Principal Software Engineer
BlueQuartz Software Dayton, Ohio mike.jackson@bluequartz.netwww.bluequartz.net
On Nov 20, 2012, at 1:56 PM, Allen D Byrne wrote:
Mike,
Are you using CMake to create the hdf5 library? There is an issue with a
definition that needs to be solved for the next release (the pre-built
binaries have this define in the H5pubconf.h).
Add
So for me to compile HDF5 1.8.10 as DLLs AND for me to use those libraries in another project my own project somehow needs to define H5_BUILT_AS_DYNAMIC_LIB in order for the proper #define 's to be enabled. This seems a bit "chicken-and-egg" to me. How do I know if HDF5 was built as a dynamic or static library? Relying on the filename is NOT a 100% way of determining this.
Looking through the HDF5 headers we get this chain.
H5public.h includes H5pubconf.h and also includes H5api_adpt.h which is the file that mainly needs the H5_BUILT_AS_DYNAMIC_LIB to be defined properly.
We can generate a new header file that gets included in H5public.h BEFORE the H5api_adpt.h file.
We could generate a new file that is included at the top of H5api_adpt.h
The H5_BUILT_AS_DYNAMIC_LIB is basically defined in hdf5-config.cmake (line 24) that gets installed when HDF5 is built with CMake which would work for my Windows and OS X builds but some of my linux distributions include their own hdf5 installations that may NOT be built with CMake at which point I guess I can fall back on file naming again.
Sorry didn't mean to confuse - debug/release - I was thinking globally about
the issue, obviously these defines have nothing to do with debug/release other
then creating another set of folders. The find_package would happen after hdf5
is installed and using cmake to read the hdf5 cmake configuration.
I was hoping to remove the build specific defines in H5pubconf.h to somewhere
else, because these defines are the only difference between static/dynamic
installs. Libraries are named unique enough.
Of course thinking about it now, there are other optional components in
H5pubconf.h! (szip/zlib/parallel...)
Allen
On Tuesday, November 20, 2012 03:27:16 PM Michael Jackson wrote:
Which "FIND_PACKAGE" sets that variable?
Inside of the Top level CMakeLists.txt file I have this now.
OPTION (BUILD_SHARED_LIBS "Build Shared Libraries" OFF)
set(H5_BUILT_AS_DYNAMIC_LIB 0)
set(H5_BUILT_AS_STATIC_LIB 1)
SET (LIB_TYPE STATIC)
SET (H5_ENABLE_SHARED_LIB NO)
SET (H5_ENABLE_STATIC_LIB NO)
IF (BUILD_SHARED_LIBS)
SET (LIB_TYPE SHARED)
ADD_DEFINITIONS (-DH5_BUILT_AS_DYNAMIC_LIB)
set(H5_BUILT_AS_DYNAMIC_LIB 1)
set(H5_BUILT_AS_STATIC_LIB 0)
SET (H5_ENABLE_SHARED_LIB YES)
ELSE (BUILD_SHARED_LIBS)
ADD_DEFINITIONS (-DH5_BUILT_AS_STATIC_LIB)
set(H5_BUILT_AS_DYNAMIC_LIB 0)
set(H5_BUILT_AS_STATIC_LIB 1)
SET (H5_ENABLE_STATIC_LIB YES)
IF (NOT WIN32)
# should this be a user setting : Everyone uses it anyway ?
ADD_DEFINITIONS (-DPIC)
ENDIF (NOT WIN32)
ENDIF (BUILD_SHARED_LIBS)
Then in config/cmake/H5pubconf.h.in I added the following:
/* Defined if HDF5 was built with CMake AND build as a shared library */ #cmakedefine H5_BUILT_AS_DYNAMIC_LIB @H5_BUILT_AS_DYNAMIC_LIB@
/* Defined if HDF5 was built with CMake AND build as a static library */ #cmakedefine H5_BUILT_AS_STATIC_LIB @H5_BUILT_AS_STATIC_LIB@
Which now allows everything to work. I am still confused why the change was
needed for Debug/Release? Ironically enough I'm the original person to put
the H5_BUILT_AS_DYNAMIC_LIB flag in the header file because when on windows
and using CMake in another project that includes HDF5 I needed to be able
to better figure out how the libraries were built so I could make decisions
on what needs to be copied into my deployment package.
The problem was that I attempted to allow multiple installs
(debug/release,
static/dynamic) of hdf5. Everything works great with cmake, because the
value is set by the FIND_PACKAGE command. However, I failed to account
for the non- cmake process. I wanted to eliminate the duplicate include
folders that would result from multiple installs.
What to do with that definition is the issue!
Allen
On Tuesday, November 20, 2012 02:04:21 PM Michael Jackson wrote:
Hmm
Looking at the H5pubconf.h for the 1.8.9 and 1.8.10 builds it would seem
that there were some merge issues maybe? Otherwise why was that
definition
removed? Not that I run the tests much (I assume if HDF5 is release then
all the tests are passing but how would any of the tests run if nothing
to
can correctly? Odd. Let me take a look. Can we get this into the first
patch release if I figure out what went wrong?
___________________________________________________________
Mike Jackson Principal Software Engineer
BlueQuartz Software Dayton, Ohio mike.jackson@bluequartz.netwww.bluequartz.net
On Nov 20, 2012, at 1:56 PM, Allen D Byrne wrote:
Mike,
Are you using CMake to create the hdf5 library? There is an issue with a
definition that needs to be solved for the next release (the pre-built
binaries have this define in the H5pubconf.h).
Add
Mike,
Considering the other config options in the H5pubconf.h file that are not
these defines - I will propose that these get replaced into the file at build
time for the patch release.
I will need to find a different solution that works for all use cases.
The change will be exactly as you mentioned and as existed in 1.8.9
Allen
···
On Tuesday, November 20, 2012 03:48:53 PM Michael Jackson wrote:
Relying on someone else NOT to rename the libraries because they monkey
around with the CMake files probably isn't a good option either. If you ask
"how are libraries named on Windows" you will get at least 2 different
answers (most likely more). With mingw they are .dylib, with msvc they
should be .dll. But where are the "Runtime" libraries installed versus the
link time libraries? some install them into lib some install them into bin.
Some install in both places. I got tired of trying to out-think the other
person and just added those symbols to the header. I have my own
"FindHDF5.cmake" that looks specifically for those symbols during my
project's configure process then can make smarter decisions based on what
it finds.
Still confused on the "... creating other folders." What other folders are
getting created?
I don't have a problem with moving the build specific defines somewhere out
of H5pubconf.h. Just let me know where you want them. I guess I'll add the
necessary version checking code to my own project to know that if we are
HDF5 1.8.10 or less I look in a certain header otherwise look in another
place. Having that define in there solves a lot of deployment problems for
windows and to some extent OS X.
Thanks
___________________________________________________________
Mike Jackson Principal Software Engineer
BlueQuartz Software Dayton, Ohio mike.jackson@bluequartz.netwww.bluequartz.net
On Nov 20, 2012, at 3:41 PM, Allen D Byrne wrote:
> Mike,
>
> Sorry didn't mean to confuse - debug/release - I was thinking globally
> about the issue, obviously these defines have nothing to do with
> debug/release other then creating another set of folders. The
> find_package would happen after hdf5 is installed and using cmake to read
> the hdf5 cmake configuration.
>
> I was hoping to remove the build specific defines in H5pubconf.h to
> somewhere else, because these defines are the only difference between
> static/dynamic installs. Libraries are named unique enough.
>
> Of course thinking about it now, there are other optional components in
> H5pubconf.h! (szip/zlib/parallel...)
>
> Allen
>
> On Tuesday, November 20, 2012 03:27:16 PM Michael Jackson wrote:
>> Which "FIND_PACKAGE" sets that variable?
>>
>> Inside of the Top level CMakeLists.txt file I have this now.
>>
>> OPTION (BUILD_SHARED_LIBS "Build Shared Libraries" OFF)
>> set(H5_BUILT_AS_DYNAMIC_LIB 0)
>> set(H5_BUILT_AS_STATIC_LIB 1)
>> SET (LIB_TYPE STATIC)
>> SET (H5_ENABLE_SHARED_LIB NO)
>> SET (H5_ENABLE_STATIC_LIB NO)
>> IF (BUILD_SHARED_LIBS)
>>
>> SET (LIB_TYPE SHARED)
>> ADD_DEFINITIONS (-DH5_BUILT_AS_DYNAMIC_LIB)
>> set(H5_BUILT_AS_DYNAMIC_LIB 1)
>> set(H5_BUILT_AS_STATIC_LIB 0)
>> SET (H5_ENABLE_SHARED_LIB YES)
>>
>> ELSE (BUILD_SHARED_LIBS)
>>
>> ADD_DEFINITIONS (-DH5_BUILT_AS_STATIC_LIB)
>> set(H5_BUILT_AS_DYNAMIC_LIB 0)
>> set(H5_BUILT_AS_STATIC_LIB 1)
>> SET (H5_ENABLE_STATIC_LIB YES)
>> IF (NOT WIN32)
>>
>> # should this be a user setting : Everyone uses it anyway ?
>> ADD_DEFINITIONS (-DPIC)
>>
>> ENDIF (NOT WIN32)
>>
>> ENDIF (BUILD_SHARED_LIBS)
>>
>>
>> Then in config/cmake/H5pubconf.h.in I added the following:
>>
>> /* Defined if HDF5 was built with CMake AND build as a shared library */
>> #cmakedefine H5_BUILT_AS_DYNAMIC_LIB @H5_BUILT_AS_DYNAMIC_LIB@
>>
>> /* Defined if HDF5 was built with CMake AND build as a static library */
>> #cmakedefine H5_BUILT_AS_STATIC_LIB @H5_BUILT_AS_STATIC_LIB@
>>
>> Which now allows everything to work. I am still confused why the change
>> was
>> needed for Debug/Release? Ironically enough I'm the original person to
>> put
>> the H5_BUILT_AS_DYNAMIC_LIB flag in the header file because when on
>> windows
>> and using CMake in another project that includes HDF5 I needed to be able
>> to better figure out how the libraries were built so I could make
>> decisions
>> on what needs to be copied into my deployment package.
>>
>> ___________________________________________________________
>> Mike Jackson Principal Software Engineer
>> BlueQuartz Software Dayton, Ohio
>> mike.jackson@bluequartz.netwww.bluequartz.net
>>
>> On Nov 20, 2012, at 2:36 PM, Allen D Byrne wrote:
>>> The problem was that I attempted to allow multiple installs
>>> (debug/release,
>>> static/dynamic) of hdf5. Everything works great with cmake, because the
>>> value is set by the FIND_PACKAGE command. However, I failed to account
>>> for the non- cmake process. I wanted to eliminate the duplicate include
>>> folders that would result from multiple installs.
>>>
>>> What to do with that definition is the issue!
>>>
>>> Allen
>>>
>>> On Tuesday, November 20, 2012 02:04:21 PM Michael Jackson wrote:
>>>> Hmm
>>>>
>>>> Looking at the H5pubconf.h for the 1.8.9 and 1.8.10 builds it would
>>>> seem
>>>>
>>>> that there were some merge issues maybe? Otherwise why was that
>>>> definition
>>>> removed? Not that I run the tests much (I assume if HDF5 is release
>>>> then
>>>> all the tests are passing but how would any of the tests run if nothing
>>>> to
>>>> can correctly? Odd. Let me take a look. Can we get this into the first
>>>> patch release if I figure out what went wrong?
>>>> ___________________________________________________________
>>>> Mike Jackson Principal Software Engineer
>>>> BlueQuartz Software Dayton, Ohio
>>>> mike.jackson@bluequartz.netwww.bluequartz.net
>>>>
>>>> On Nov 20, 2012, at 1:56 PM, Allen D Byrne wrote:
>>>>> Mike,
>>>>>
>>>>> Are you using CMake to create the hdf5 library? There is an issue with
>>>>> a
>>>>> definition that needs to be solved for the next release (the pre-built
>>>>> binaries have this define in the H5pubconf.h).
>>>>> Add
>>>>>
>>>>> #define H5_BUILT_AS_DYNAMIC_LIB 1
>>>>>
>>>>> in your H5pubconf.h file after building HDF5.
>>>>>
>>>>> Allen
Mike,
I did not mean to imply that the filenames determine how they were built,
the filenames can be made different to allow installation in the same folder.
This define was (until now) the only issue keeping the include files from being
installed in the same "include folder". I had thought I solved it for CMake
use and now see otherwise.
Also, I now see and understand that there are a mixture of configuration and
machine defines being stored in the file and I will put the define back into the
H5pubconf.h for the next release (there might be a patch released soon
anyways).
I was hoping for an elegant solution to the "install multiple configurations"
issue, but there might not be one.
Allen
···
On Wednesday, November 21, 2012 09:17:20 AM Michael Jackson wrote:
So for me to compile HDF5 1.8.10 as DLLs AND for me to use those libraries
in another project my own project somehow needs to define
H5_BUILT_AS_DYNAMIC_LIB in order for the proper #define 's to be enabled.
This seems a bit "chicken-and-egg" to me. How do I know if HDF5 was built
as a dynamic or static library? Relying on the filename is NOT a 100% way
of determining this.
Looking through the HDF5 headers we get this chain.
H5public.h includes H5pubconf.h and also includes H5api_adpt.h which is the
file that mainly needs the H5_BUILT_AS_DYNAMIC_LIB to be defined properly.
We can generate a new header file that gets included in H5public.h BEFORE
the H5api_adpt.h file.
We could generate a new file that is included at the top of H5api_adpt.h
The H5_BUILT_AS_DYNAMIC_LIB is basically defined in hdf5-config.cmake (line
24) that gets installed when HDF5 is built with CMake which would work for
my Windows and OS X builds but some of my linux distributions include their
own hdf5 installations that may NOT be built with CMake at which point I
guess I can fall back on file naming again.
On Nov 20, 2012, at 3:41 PM, Allen D Byrne wrote:
> Mike,
>
> Sorry didn't mean to confuse - debug/release - I was thinking globally
> about the issue, obviously these defines have nothing to do with
> debug/release other then creating another set of folders. The
> find_package would happen after hdf5 is installed and using cmake to read
> the hdf5 cmake configuration.
>
> I was hoping to remove the build specific defines in H5pubconf.h to
> somewhere else, because these defines are the only difference between
> static/dynamic installs. Libraries are named unique enough.
>
> Of course thinking about it now, there are other optional components in
> H5pubconf.h! (szip/zlib/parallel...)
>
> Allen
>
> On Tuesday, November 20, 2012 03:27:16 PM Michael Jackson wrote:
>> Which "FIND_PACKAGE" sets that variable?
>>
>> Inside of the Top level CMakeLists.txt file I have this now.
>>
>> OPTION (BUILD_SHARED_LIBS "Build Shared Libraries" OFF)
>> set(H5_BUILT_AS_DYNAMIC_LIB 0)
>> set(H5_BUILT_AS_STATIC_LIB 1)
>> SET (LIB_TYPE STATIC)
>> SET (H5_ENABLE_SHARED_LIB NO)
>> SET (H5_ENABLE_STATIC_LIB NO)
>> IF (BUILD_SHARED_LIBS)
>>
>> SET (LIB_TYPE SHARED)
>> ADD_DEFINITIONS (-DH5_BUILT_AS_DYNAMIC_LIB)
>> set(H5_BUILT_AS_DYNAMIC_LIB 1)
>> set(H5_BUILT_AS_STATIC_LIB 0)
>> SET (H5_ENABLE_SHARED_LIB YES)
>>
>> ELSE (BUILD_SHARED_LIBS)
>>
>> ADD_DEFINITIONS (-DH5_BUILT_AS_STATIC_LIB)
>> set(H5_BUILT_AS_DYNAMIC_LIB 0)
>> set(H5_BUILT_AS_STATIC_LIB 1)
>> SET (H5_ENABLE_STATIC_LIB YES)
>> IF (NOT WIN32)
>>
>> # should this be a user setting : Everyone uses it anyway ?
>> ADD_DEFINITIONS (-DPIC)
>>
>> ENDIF (NOT WIN32)
>>
>> ENDIF (BUILD_SHARED_LIBS)
>>
>>
>> Then in config/cmake/H5pubconf.h.in I added the following:
>>
>> /* Defined if HDF5 was built with CMake AND build as a shared library */
>> #cmakedefine H5_BUILT_AS_DYNAMIC_LIB @H5_BUILT_AS_DYNAMIC_LIB@
>>
>> /* Defined if HDF5 was built with CMake AND build as a static library */
>> #cmakedefine H5_BUILT_AS_STATIC_LIB @H5_BUILT_AS_STATIC_LIB@
>>
>> Which now allows everything to work. I am still confused why the change
>> was
>> needed for Debug/Release? Ironically enough I'm the original person to
>> put
>> the H5_BUILT_AS_DYNAMIC_LIB flag in the header file because when on
>> windows
>> and using CMake in another project that includes HDF5 I needed to be able
>> to better figure out how the libraries were built so I could make
>> decisions
>> on what needs to be copied into my deployment package.
>>
>> ___________________________________________________________
>> Mike Jackson Principal Software Engineer
>> BlueQuartz Software Dayton, Ohio
>> mike.jackson@bluequartz.netwww.bluequartz.net
>>
>> On Nov 20, 2012, at 2:36 PM, Allen D Byrne wrote:
>>> The problem was that I attempted to allow multiple installs
>>> (debug/release,
>>> static/dynamic) of hdf5. Everything works great with cmake, because the
>>> value is set by the FIND_PACKAGE command. However, I failed to account
>>> for the non- cmake process. I wanted to eliminate the duplicate include
>>> folders that would result from multiple installs.
>>>
>>> What to do with that definition is the issue!
>>>
>>> Allen
>>>
>>> On Tuesday, November 20, 2012 02:04:21 PM Michael Jackson wrote:
>>>> Hmm
>>>>
>>>> Looking at the H5pubconf.h for the 1.8.9 and 1.8.10 builds it would
>>>> seem
>>>>
>>>> that there were some merge issues maybe? Otherwise why was that
>>>> definition
>>>> removed? Not that I run the tests much (I assume if HDF5 is release
>>>> then
>>>> all the tests are passing but how would any of the tests run if nothing
>>>> to
>>>> can correctly? Odd. Let me take a look. Can we get this into the first
>>>> patch release if I figure out what went wrong?
>>>> ___________________________________________________________
>>>> Mike Jackson Principal Software Engineer
>>>> BlueQuartz Software Dayton, Ohio
>>>> mike.jackson@bluequartz.netwww.bluequartz.net
>>>>
>>>> On Nov 20, 2012, at 1:56 PM, Allen D Byrne wrote:
>>>>> Mike,
>>>>>
>>>>> Are you using CMake to create the hdf5 library? There is an issue with
>>>>> a
>>>>> definition that needs to be solved for the next release (the pre-built
>>>>> binaries have this define in the H5pubconf.h).
>>>>> Add
>>>>>
>>>>> #define H5_BUILT_AS_DYNAMIC_LIB 1
>>>>>
>>>>> in your H5pubconf.h file after building HDF5.
>>>>>
>>>>> Allen
Ok, I see what you are saying about Debug and Release but this is where one would NOT want to include anything in the header files that determine if we are in DEBUG or RELEASE mode. Let the compiler do that since they all do anyways. I have yet to see a project that did NOT define either "NDEBUG" or "DEBUG" for their compiles.
Unless you are talking not about combining Debug/Release into the same directory but Static/Dynamic into the same directory. I would agree that the H5_BUILT_AS_DYNAMIC_LIB define would definitely mess that up.
Mike,
I did not mean to imply that the filenames determine how they were built,
the filenames can be made different to allow installation in the same folder.
This define was (until now) the only issue keeping the include files from being
installed in the same "include folder". I had thought I solved it for CMake
use and now see otherwise.
Also, I now see and understand that there are a mixture of configuration and
machine defines being stored in the file and I will put the define back into the
H5pubconf.h for the next release (there might be a patch released soon
anyways).
I was hoping for an elegant solution to the "install multiple configurations"
issue, but there might not be one.
Allen
On Wednesday, November 21, 2012 09:17:20 AM Michael Jackson wrote:
So for me to compile HDF5 1.8.10 as DLLs AND for me to use those libraries
in another project my own project somehow needs to define
H5_BUILT_AS_DYNAMIC_LIB in order for the proper #define 's to be enabled.
This seems a bit "chicken-and-egg" to me. How do I know if HDF5 was built
as a dynamic or static library? Relying on the filename is NOT a 100% way
of determining this.
Looking through the HDF5 headers we get this chain.
H5public.h includes H5pubconf.h and also includes H5api_adpt.h which is the
file that mainly needs the H5_BUILT_AS_DYNAMIC_LIB to be defined properly.
We can generate a new header file that gets included in H5public.h BEFORE
the H5api_adpt.h file.
We could generate a new file that is included at the top of H5api_adpt.h
The H5_BUILT_AS_DYNAMIC_LIB is basically defined in hdf5-config.cmake (line
24) that gets installed when HDF5 is built with CMake which would work for
my Windows and OS X builds but some of my linux distributions include their
own hdf5 installations that may NOT be built with CMake at which point I
guess I can fall back on file naming again.
Sorry didn't mean to confuse - debug/release - I was thinking globally
about the issue, obviously these defines have nothing to do with
debug/release other then creating another set of folders. The
find_package would happen after hdf5 is installed and using cmake to read
the hdf5 cmake configuration.
I was hoping to remove the build specific defines in H5pubconf.h to
somewhere else, because these defines are the only difference between
static/dynamic installs. Libraries are named unique enough.
Of course thinking about it now, there are other optional components in
H5pubconf.h! (szip/zlib/parallel...)
Allen
On Tuesday, November 20, 2012 03:27:16 PM Michael Jackson wrote:
Which "FIND_PACKAGE" sets that variable?
Inside of the Top level CMakeLists.txt file I have this now.
OPTION (BUILD_SHARED_LIBS "Build Shared Libraries" OFF)
set(H5_BUILT_AS_DYNAMIC_LIB 0)
set(H5_BUILT_AS_STATIC_LIB 1)
SET (LIB_TYPE STATIC)
SET (H5_ENABLE_SHARED_LIB NO)
SET (H5_ENABLE_STATIC_LIB NO)
IF (BUILD_SHARED_LIBS)
SET (LIB_TYPE SHARED)
ADD_DEFINITIONS (-DH5_BUILT_AS_DYNAMIC_LIB)
set(H5_BUILT_AS_DYNAMIC_LIB 1)
set(H5_BUILT_AS_STATIC_LIB 0)
SET (H5_ENABLE_SHARED_LIB YES)
ELSE (BUILD_SHARED_LIBS)
ADD_DEFINITIONS (-DH5_BUILT_AS_STATIC_LIB)
set(H5_BUILT_AS_DYNAMIC_LIB 0)
set(H5_BUILT_AS_STATIC_LIB 1)
SET (H5_ENABLE_STATIC_LIB YES)
IF (NOT WIN32)
# should this be a user setting : Everyone uses it anyway ?
ADD_DEFINITIONS (-DPIC)
ENDIF (NOT WIN32)
ENDIF (BUILD_SHARED_LIBS)
Then in config/cmake/H5pubconf.h.in I added the following:
/* Defined if HDF5 was built with CMake AND build as a shared library */ #cmakedefine H5_BUILT_AS_DYNAMIC_LIB @H5_BUILT_AS_DYNAMIC_LIB@
/* Defined if HDF5 was built with CMake AND build as a static library */ #cmakedefine H5_BUILT_AS_STATIC_LIB @H5_BUILT_AS_STATIC_LIB@
Which now allows everything to work. I am still confused why the change
was
needed for Debug/Release? Ironically enough I'm the original person to
put
the H5_BUILT_AS_DYNAMIC_LIB flag in the header file because when on
windows
and using CMake in another project that includes HDF5 I needed to be able
to better figure out how the libraries were built so I could make
decisions
on what needs to be copied into my deployment package.
The problem was that I attempted to allow multiple installs
(debug/release,
static/dynamic) of hdf5. Everything works great with cmake, because the
value is set by the FIND_PACKAGE command. However, I failed to account
for the non- cmake process. I wanted to eliminate the duplicate include
folders that would result from multiple installs.
What to do with that definition is the issue!
Allen
On Tuesday, November 20, 2012 02:04:21 PM Michael Jackson wrote:
Hmm
Looking at the H5pubconf.h for the 1.8.9 and 1.8.10 builds it would
seem
that there were some merge issues maybe? Otherwise why was that
definition
removed? Not that I run the tests much (I assume if HDF5 is release
then
all the tests are passing but how would any of the tests run if nothing
to
can correctly? Odd. Let me take a look. Can we get this into the first
patch release if I figure out what went wrong?
___________________________________________________________
Mike Jackson Principal Software Engineer
BlueQuartz Software Dayton, Ohio mike.jackson@bluequartz.netwww.bluequartz.net
On Nov 20, 2012, at 1:56 PM, Allen D Byrne wrote:
Mike,
Are you using CMake to create the hdf5 library? There is an issue with
a
definition that needs to be solved for the next release (the pre-built
binaries have this define in the H5pubconf.h).
Add
