I am using HDF5 1.8.5 libraries. I have a C program in HDF5 and while
building it I get following errors:
Error 2 error LNK2019: unresolved external symbol _SZ_encoder_enabled
referenced in function _H5Z_init_interface hdf5.lib
Error 3 error LNK2019: unresolved external symbol _SZ_BufftoBuffCompress
referenced in function _H5Z_filter_szip hdf5.lib
Error 4 error LNK2019: unresolved external symbol _SZ_BufftoBuffDecompress
referenced in function _H5Z_filter_szip hdf5.lib
Error 5 error LNK2019: unresolved external symbol _compress2 referenced in
function _H5Z_filter_deflate hdf5.lib
Error 6 error LNK2019: unresolved external symbol _inflateEnd referenced in
function _H5Z_filter_deflate hdf5.lib
Error 7 error LNK2019: unresolved external symbol _inflate referenced in
function _H5Z_filter_deflate hdf5.lib
Error 8 error LNK2019: unresolved external symbol _inflateInit_ referenced
in function _H5Z_filter_deflate hdf5.lib
Error 9 fatal error LNK1120: 7 unresolved externals
C:\..\sampleProgram\Debug\TestInC.exe 1
I checked all the addional libraries I am using and I found everything in
place. I have these libs in the list of link llibraries as you mentioned.
Currently, I don't see any link error but there is a runtime error "unable
to locate component". It says zlib1.dll cannot found. Any Idea??
I have a counter measure for the same to include path of this dll as PATH in
the environmet variables path. But, I would be more happy if I can avoid
this. Could you help me on this???
Hi Santosh.
I'm assuming that you are trying to build an app or dll for windows linking
against the BINARY version of the HDF5 library, i.e. using it "off the
shelf".
In this case, ensure that you are using the
hdf5-1.8.5-win32\dll path, NOT the
hdf5-1.8.5-win32\lib
path as your source of lib files. This dll directory also contains all the
dlls you need, including zlib1.dll.
That solved my problems when building with VC++ 2005, I can't comment on
2008, since we don't have that available yet here (!!)
Regarding env vars, if you're only building ONE app, then you could simply
package your app along with all the hdf5 dlls in your application's .exe
directory, then you won't need an env var. But in general, if writing
several apps that are not colocated, then better to amend PATH to point to
the hdf5 dlls, rather than copying hdf5 for all the various apps.
Hi Santosh, no nothing silly, this one caught me out too. You need to define
H5_BUILT_AS_DYNAMIC_LIB in your project
properties/c++/preprocessor/preprocessor definitions.
Without this defined, none of the global variables are visible to the
linker, despite being declared as dll exported. This doesn't appear to be
documented, I found it scanning the source distribution.
Steve
Steve,
H5_BUILT_AS_DYNAMIC_LIB should only be used if you are building with CMake. Undefined indicates that the original definitions should be used. This is what is needed by the project files. Using the project files requires that copy_hdf.bat is used before anything else is done. 1.8.5 expects VS2005 and VS2008 requires the project files to be upgraded. Loading the all solution file and saving after the upgrade should be enough.
This assumes you are building from source.
The pre-built files were built with VS2005. Also note that you should use the external libs (szip,zlib) that were used to build the binaries and packaged with them.
Allen
···
Hi Santosh, no nothing silly, this one caught me out too. You need to define
H5_BUILT_AS_DYNAMIC_LIB in your project
properties/c++/preprocessor/preprocessor definitions.
Without this defined, none of the global variables are visible to the
linker, despite being declared as dll exported. This doesn't appear to be
documented, I found it scanning the source distribution.
Steve
Um. Time out. I am just now getting caught up with this thread BUT I think that variable is ONLY available if you build HDF5 with CMake and THEN it will be defined in a header file. If you do NOT build HDF5 with CMake then I think there is the HDF5_USE_DLL or something like that.
···
___________________________________________________________
Mike Jackson www.bluequartz.net
Principal Software Engineer mike.jackson@bluequartz.net
BlueQuartz Software Dayton, Ohio
On Nov 11, 2010, at 10:53 AM, Steve Bissell wrote:
Hi Santosh, no nothing silly, this one caught me out too. You need to define
H5_BUILT_AS_DYNAMIC_LIB in your project
properties/c++/preprocessor/preprocessor definitions.
Without this defined, none of the global variables are visible to the
linker, despite being declared as dll exported. This doesn't appear to be
documented, I found it scanning the source distribution.
Steve
--
View this message in context: http://hdf-forum.184993.n3.nabble.com/VC-project-Build-Errors-with-HDF5-1-8-5-tp1880934p1883323.html
Sent from the hdf-forum mailing list archive at Nabble.com.
Um. Time out. I am just now getting caught up with this thread BUT I
think that variable is ONLY available if you build HDF5 with CMake and
THEN it will be defined in a header file. If you do NOT build HDF5 with
CMake then I think there is the HDF5_USE_DLL or something like that.
___________________________________________________________
Mike Jackson www.bluequartz.net
Principal Software Engineer mike.jackson@bluequartz.net
BlueQuartz Software Dayton, Ohio
On Nov 11, 2010, at 10:53 AM, Steve Bissell wrote:
Hi Santosh, no nothing silly, this one caught me out too. You need to define
H5_BUILT_AS_DYNAMIC_LIB in your project
properties/c++/preprocessor/preprocessor definitions.
Without this defined, none of the global variables are visible to the
linker, despite being declared as dll exported. This doesn't appear to be
documented, I found it scanning the source distribution.
Steve
--
View this message in context: http://hdf-forum.184993.n3.nabble.com/VC-project-Build-Errors-with-HDF5-1-8-5-tp1880934p1883323.html
Sent from the hdf-forum mailing list archive at Nabble.com.
Hi All.
My reason for setting H5_BUILT_AS_DYNAMIC_LIB is based on the fact that
1) h5api_adpt.h uses it as a #ifdef switch to define H5_DLLVAR,
2) AND, the #else branch of this (which references the _HDF5USEDLL_ ifdef)
is very clearly marked thus in the comments:
/* This is the original HDFGroup defined preprocessor code which should
still work
* with the VS projects that are maintained by "The HDF Group"
* This will be removed after the next release.
*/
The statement "this will be removed in the next release" led me to assume
that this section of the header is deprecated and should not be used in new
code, and hence that the best define to use would be
H5_BUILT_AS_DYNAMIC_LIB.
Is this interpretation incorrect - will this section of the header continue
to exist in future?
I don't use CMake, and I'm not building HDF5, just using it from my client
code.
So what, if any, are the functional consequences to VS2005 projects client
code defining H5_BUILT_AS_DYNAMIC_LIB and building against the h, lib binary
deliverable - bearing in mind that my application is built, tested, and
seems to be working fine....?
Steve
Hi All.
My reason for setting H5_BUILT_AS_DYNAMIC_LIB is based on the fact that
1) h5api_adpt.h uses it as a #ifdef switch to define H5_DLLVAR,
2) AND, the #else branch of this (which references the _HDF5USEDLL_ ifdef)
is very clearly marked thus in the comments:
/* This is the original HDFGroup defined preprocessor code which should
still work
* with the VS projects that are maintained by "The HDF Group"
* This will be removed after the next release.
*/
The last line is misleading and will be fixed. There are no plans to drop the VS projects in the HDF5 1.8.* series.
The switch will happen only in the major release. The next one is 1.10.0, and release date was not set up yet.
Thank you!
Elena
···
On Nov 12, 2010, at 4:23 AM, Steve Bissell wrote:
The statement "this will be removed in the next release" led me to assume
that this section of the header is deprecated and should not be used in new
code, and hence that the best define to use would be
H5_BUILT_AS_DYNAMIC_LIB.
Is this interpretation incorrect - will this section of the header continue
to exist in future?
I don't use CMake, and I'm not building HDF5, just using it from my client
code.
So what, if any, are the functional consequences to VS2005 projects client
code defining H5_BUILT_AS_DYNAMIC_LIB and building against the h, lib binary
deliverable - bearing in mind that my application is built, tested, and
seems to be working fine....?
Steve
--
View this message in context: http://hdf-forum.184993.n3.nabble.com/VC-project-Build-Errors-with-HDF5-1-8-5-tp1880934p1888067.html
Sent from the hdf-forum mailing list archive at Nabble.com.
As Elena mentioned, that was an error in the comments. It should have been something like the following:
The Visual Studio project files be not be supported in the next major release of 1.10
As far as :
So what, if any, are the functional consequences to VS2005 projects client
code defining H5_BUILT_AS_DYNAMIC_LIB and building against the h, lib binary
deliverable - bearing in mind that my application is built, tested, and
seems to be working fine....?
Building applications using the dynamic libs/dlls means you will be importing the libraries and defining just H5_BUILT_AS_DYNAMIC_LIB will bypass all the exports blocks arriving at lines 87,88: #define H5_DLL __declspec(dllimport) #define H5_DLLVAR __declspec(dllimport)
Similiarly, all the other defines will be imports.
Not defining H5_BUILT_AS_DYNAMIC_LIB will skip to the else block at line 290: #if defined(_WIN32)
which then will check the existence/value of the original defines to set each of the defines mentioned previously.
--- So that if _HDF5DLL_ is not defined and _HDF5USEDLL_ is defined - lines 297,298: #define H5_DLL __declspec(dllimport) #define H5_DLLVAR __declspec(dllimport)
and similiarly the other defines will check for 'USE' defines to set the the other defines.
NOTE: if neither _HDF5DLL_ or _HDF5USEDLL_ is defined, then the defines will be set at lines 300,301: #define H5_DLL #define H5_DLLVAR extern
Which may cause problems! Therefore because you have defined H5_BUILT_AS_DYNAMIC_LIB, you have set all defines to __declspec(dllimport) and can ignore worying about all the 'USE' defines.
Allen
···
Hi All.
My reason for setting H5_BUILT_AS_DYNAMIC_LIB is based on the fact that
1) h5api_adpt.h uses it as a #ifdef switch to define H5_DLLVAR,
2) AND, the #else branch of this (which references the _HDF5USEDLL_ ifdef)
is very clearly marked thus in the comments:
/* This is the original HDFGroup defined preprocessor code which should
still work
* with the VS projects that are maintained by "The HDF Group"
* This will be removed after the next release.
*/
The statement "this will be removed in the next release" led me to assume
that this section of the header is deprecated and should not be used in new
code, and hence that the best define to use would be
H5_BUILT_AS_DYNAMIC_LIB.
Is this interpretation incorrect - will this section of the header continue
to exist in future?
I don't use CMake, and I'm not building HDF5, just using it from my client
code.
So what, if any, are the functional consequences to VS2005 projects client
code defining H5_BUILT_AS_DYNAMIC_LIB and building against the h, lib binary
deliverable - bearing in mind that my application is built, tested, and
seems to be working fine....?
Steve
Let me try to explain some more because I was the one who added the H5_BUILT_AS_DYNAMIC_LIB variable. The reason this variable was needed was because projects that _use_ HDF5 and want to deploy their application to another machine need some sort of mechanism to correctly determine if the HDF5 project was built as a static or dynamic library. Using file extensions and other filenaming schemes are NOT good enough as someone could change the file names. This is a problem on Windows as there is NO set naming convention for libraries and no direction from Microsoft so really anything goes. When HDF5 is built using CMake this variable is written into another header file (H5pubconf.h) which is then pulled in by another header (H5public.h).
So start with H5Public.h file. This FIRST includes the H5pubconf.h file which is generated by CMake or autotools. Within H5pubconf.h the H5_BUILT_AS_DYNAMIC_LIB is either defined to 1 or NOT defined at all based on how HDF5 is being built. Further down in H5Public.h is the #include "H5api_adpt.h" which brings in all the Windows DLL defines that are needed in order to correctly export the functions in HDF5 library when compiling on windows (and to some extend GCC). If you follow this flow then you will see that there is NO need to define H5_BUILT_AS_DYNAMIC_LIB yourself in ANY project. And in fact doing so may create problems for your project.
Actually the use of _HDF5USEDLL_ can actually be completely gotten rid of in the Visual Studio projects with some fixes to the current logic that is contained in the preprocessor blocks. I think at one point I had a patch that got rid of it but it never got picked up.
___________________________________________________________
Mike Jackson www.bluequartz.net
Principal Software Engineer mike.jackson@bluequartz.net
BlueQuartz Software Dayton, Ohio
On Nov 12, 2010, at 10:21 AM, Allen D Byrne wrote:
As Elena mentioned, that was an error in the comments. It should have been something like the following:
The Visual Studio project files be not be supported in the next major release of 1.10
As far as :
> So what, if any, are the functional consequences to VS2005 projects client
> code defining H5_BUILT_AS_DYNAMIC_LIB and building against the h, lib binary
> deliverable - bearing in mind that my application is built, tested, and
> seems to be working fine....?
Building applications using the dynamic libs/dlls means you will be importing the libraries and defining just H5_BUILT_AS_DYNAMIC_LIB will bypass all the exports blocks arriving at lines 87,88: #define H5_DLL __declspec(dllimport) #define H5_DLLVAR __declspec(dllimport)
Similiarly, all the other defines will be imports.
Not defining H5_BUILT_AS_DYNAMIC_LIB will skip to the else block at line 290: #if defined(_WIN32)
which then will check the existence/value of the original defines to set each of the defines mentioned previously.
--- So that if _HDF5DLL_ is not defined and _HDF5USEDLL_ is defined - lines 297,298: #define H5_DLL __declspec(dllimport) #define H5_DLLVAR __declspec(dllimport)
and similiarly the other defines will check for 'USE' defines to set the the other defines.
NOTE: if neither _HDF5DLL_ or _HDF5USEDLL_ is defined, then the defines will be set at lines 300,301: #define H5_DLL #define H5_DLLVAR extern
Which may cause problems! Therefore because you have defined H5_BUILT_AS_DYNAMIC_LIB, you have set all defines to __declspec(dllimport) and can ignore worying about all the 'USE' defines.
Allen
>
> Hi All.
> My reason for setting H5_BUILT_AS_DYNAMIC_LIB is based on the fact that
> 1) h5api_adpt.h uses it as a #ifdef switch to define H5_DLLVAR,
> 2) AND, the #else branch of this (which references the _HDF5USEDLL_ ifdef)
> is very clearly marked thus in the comments:
>
> /* This is the original HDFGroup defined preprocessor code which should
> still work
> * with the VS projects that are maintained by "The HDF Group"
> * This will be removed after the next release.
> */
>
> The statement "this will be removed in the next release" led me to assume
> that this section of the header is deprecated and should not be used in new
> code, and hence that the best define to use would be
> H5_BUILT_AS_DYNAMIC_LIB.
>
> Is this interpretation incorrect - will this section of the header continue
> to exist in future?
>
> I don't use CMake, and I'm not building HDF5, just using it from my client
> code.
> So what, if any, are the functional consequences to VS2005 projects client
> code defining H5_BUILT_AS_DYNAMIC_LIB and building against the h, lib binary
> deliverable - bearing in mind that my application is built, tested, and
> seems to be working fine....?
> Steve
>
_______________________________________________
Hdf-forum is for HDF software users discussion. Hdf-forum@hdfgroup.org http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org
Hi Mike, Allen, Elena - thanks for the feedback.
I've shifted projects for the moment, but when I get back onto this for the
next set of requirements in the pipeline, I'll change the preprocessor
definition to the "approved" _HDF5USEDLL_ and re-run the functionality
tests, just in case!
So I'm going to assume that, until 1.10 at least, that section of the header
will be available.
When 1.10 IS scheduled, some notes about the changes in this area (of
linking a client app against the headers) would be appreciated, although I'm
pretty used to inferring things from source code, it's good to have
independent guidance via documentation, to prevent the kind of
misunderstanding that I just had
Steve
