HDF .NET wrappers, x64

Hdf-forum archives
1

Hello HDF world--
I am working on compiling the .NET wrappers for HDF for the x64
architecture. Does anyone out there have experience building these wrappers,
whether in 32 bit mode or 64 bit mode? I would love to get in touch with
you.

Here is the problem I am having

The code downloaded from the HDF group (i.e. from
ftp://ftp.hdfgroup.uiuc.edu/pub/outgoing/hdf5/HDF5dotNetEnv/hdf5DotNet18.zip)
does not link against HDF binaries as provided, even on x86 (Win32).

There are a few DllExport issues which prevent the link, for instance:

1>H5O.obj : error LNK2001: unresolved external symbol "extern "C" int
__cdecl H5Oget_info(int,struct H5O_info_t *)" (?H5Oget_info@
@$$J0YAHHPAUH5O_info_t@@@Z)

Which can be fixed by putting the usual DllImport attribute on the relevant
function in H5O.cpp, i.e.

[DllImport("hdf5dll.dll",
           CharSet=CharSet::Auto,
           CallingConvention=CallingConvention::StdCall)]

There are a few of these. But once these are solved, 13 linking errors
related to the global ints H5P_CLS_XXX_g remain, e.g.

1>H5P.obj : error LNK2001: unresolved external symbol
__imp__H5P_CLS_OBJECT_CREATE_g

bindump and depends agree that these symbols are most certainly exported
from hdf5dll.dll as provided by the HDF group, so I can't tell what it's
complaining about. While one can never be sure, I think I've eliminated the
usual suspects (different run-time libraries, linking options, accidental
mixed 32 & 64 bit code generation, etc.).

(_HDF5USEDLL_is indeed defined in the HDF5DotNet project so that all the
functions and variable references which should be found in the external unit
are properly decorated with declspec(dllimport) in the wrapper library.)

Has anyone run into this sort of problem before?

Many many thanks for any advice.

Sebastian Good
Palladium Consulting

2

Sebastian,

The binaries from the hdfgroup are built with vs2005. I use vs2008 and have
successfully built them as well as the read_hdf and h4toh5 systems.

It takes knowledge of the Visual Studio libraries and how to include them in
the link line.

I installed the binary libraries under C:\ HDF4.2r3 and C:\ HDF5-1.8.2 and
then when linking you have two choices:

1) you can edit each project separately to add the LIB path; or

2) you can edit your project VC++ directories properties and add both
include and lib directories for all builds.

I did number 2, curious though, in the build the h4toh5 executables, I had
to exclude the LIBCMT.LIB library on a project by project basis.

John Huddleston, PhD, PE

···

_____

From: Sebastian Good [mailto:sebastian@palladiumconsulting.com]
Sent: Thursday, December 18, 2008 12:10 AM
To: hdf-forum@hdfgroup.org
Subject: [hdf-forum] HDF .NET wrappers, x64

Hello HDF world--

I am working on compiling the .NET wrappers for HDF for the x64
architecture. Does anyone out there have experience building these wrappers,
whether in 32 bit mode or 64 bit mode? I would love to get in touch with
you.

Here is the problem I am having

The code downloaded from the HDF group (i.e. from
ftp://ftp.hdfgroup.uiuc.edu/pub/outgoing/hdf5/HDF5dotNetEnv/hdf5DotNet18.zip
) does not link against HDF binaries as provided, even on x86 (Win32).

There are a few DllExport issues which prevent the link, for instance:

1>H5O.obj : error LNK2001: unresolved external symbol "extern "C" int
__cdecl H5Oget_info(int,struct H5O_info_t *)"
(?H5Oget_info@@$$J0YAHHPAUH5O_info_t@@@Z)

Which can be fixed by putting the usual DllImport attribute on the relevant
function in H5O.cpp, i.e.

[DllImport("hdf5dll.dll",
           CharSet=CharSet::Auto,
           CallingConvention=CallingConvention::StdCall)]

There are a few of these. But once these are solved, 13 linking errors
related to the global ints H5P_CLS_XXX_g remain, e.g.

1>H5P.obj : error LNK2001: unresolved external symbol
__imp__H5P_CLS_OBJECT_CREATE_g

bindump and depends agree that these symbols are most certainly exported
from hdf5dll.dll as provided by the HDF group, so I can't tell what it's
complaining about. While one can never be sure, I think I've eliminated the
usual suspects (different run-time libraries, linking options, accidental
mixed 32 & 64 bit code generation, etc.).

(_HDF5USEDLL_is indeed defined in the HDF5DotNet project so that all the
functions and variable references which should be found in the external unit
are properly decorated with declspec(dllimport) in the wrapper library.)

Has anyone run into this sort of problem before?

Many many thanks for any advice.

Sebastian Good

Palladium Consulting

3

Good afternoon Sebastian,

You have to make two configuration changes to your Visual Studio software to
build the wrapper.

1) edit the project properties - linker - input - additional dependencies
and change the path to those two LIB files to your local C: drive path to
the HDF library binaries. In my case it is C:\ HDF5-1.8.2\dll Note the
'dll' and not the 'lib' as came from the distribution.

2) edit the Tools - Options - Projects and Solutions - VC++ Directories -
Executable files and add the $(SystemRoot)\system32 to the list if it is not
already there.

John Huddleston, PhD, PE

···

_____

From: Sebastian Good [mailto:sebastian@palladiumconsulting.com]
Sent: Thursday, December 18, 2008 6:18 PM
To: jhuddleston@hughes.net
Subject: Re: [hdf-forum] HDF .NET wrappers, x64

Hi John, thanks for writing. I have also been able to build the raw HDF
binaries with VS 2005 (using option (2) as you describe above also), but I
cannot successfully compile the HDF5DotNet wrapper project. Have you
experience with this?

Cheers,

Sebastian

On Thu, Dec 18, 2008 at 5:30 PM, John Huddleston <jhuddleston@hughes.net> wrote:

Sebastian,

The binaries from the hdfgroup are built with vs2005. I use vs2008 and have
successfully built them as well as the read_hdf and h4toh5 systems.

It takes knowledge of the Visual Studio libraries and how to include them in
the link line.

I installed the binary libraries under C:\ HDF4.2r3 and C:\ HDF5-1.8.2 and
then when linking you have two choices:

1) you can edit each project separately to add the LIB path; or

2) you can edit your project VC++ directories properties and add both
include and lib directories for all builds.

I did number 2, curious though, in the build the h4toh5 executables, I had
to exclude the LIBCMT.LIB library on a project by project basis.

John Huddleston, PhD, PE

  _____

From: Sebastian Good [mailto:sebastian@palladiumconsulting.com]
Sent: Thursday, December 18, 2008 12:10 AM
To: hdf-forum@hdfgroup.org
Subject: [hdf-forum] HDF .NET wrappers, x64

Hello HDF world--

I am working on compiling the .NET wrappers for HDF for the x64
architecture. Does anyone out there have experience building these wrappers,
whether in 32 bit mode or 64 bit mode? I would love to get in touch with
you.

Here is the problem I am having

The code downloaded from the HDF group (i.e. from
ftp://ftp.hdfgroup.uiuc.edu/pub/outgoing/hdf5/HDF5dotNetEnv/hdf5DotNet18.zip
) does not link against HDF binaries as provided, even on x86 (Win32).

There are a few DllExport issues which prevent the link, for instance:

1>H5O.obj : error LNK2001: unresolved external symbol "extern "C" int
__cdecl H5Oget_info(int,struct H5O_info_t *)"
(?H5Oget_info@@$$J0YAHHPAUH5O_info_t@@@Z)

Which can be fixed by putting the usual DllImport attribute on the relevant
function in H5O.cpp, i.e.

[DllImport("hdf5dll.dll",
           CharSet=CharSet::Auto,
           CallingConvention=CallingConvention::StdCall)]

There are a few of these. But once these are solved, 13 linking errors
related to the global ints H5P_CLS_XXX_g remain, e.g.

1>H5P.obj : error LNK2001: unresolved external symbol
__imp__H5P_CLS_OBJECT_CREATE_g

bindump and depends agree that these symbols are most certainly exported
from hdf5dll.dll as provided by the HDF group, so I can't tell what it's
complaining about. While one can never be sure, I think I've eliminated the
usual suspects (different run-time libraries, linking options, accidental
mixed 32 & 64 bit code generation, etc.).

(_HDF5USEDLL_is indeed defined in the HDF5DotNet project so that all the
functions and variable references which should be found in the external unit
are properly decorated with declspec(dllimport) in the wrapper library.)

Has anyone run into this sort of problem before?

Many many thanks for any advice.

Sebastian Good

Palladium Consulting

4

John,

Thanks again for writing. Adding the DLLs as a dependency instead of the LIB
files results in

1>C:\dev\bpa\src\Hdf-1.8\lib\x86\Release\hdf5dll.dll : fatal error LNK1107:
invalid or corrupt file: cannot read at 0x2A8

I've always linked to the lib files on the Windows platform, not the DLLs.
I'm certain I'm just neglecting one entirely obvious switch somewhere, but I
just don't know where!

Cheers,

Sebastian

···

From: John Huddleston [mailto:jhuddleston@hughes.net]
Sent: Friday, December 19, 2008 3:44 PM
To: 'Sebastian Good'; hdf-forum@hdfgroup.org
Subject: RE: [hdf-forum] HDF .NET wrappers, x64

Good afternoon Sebastian,

You have to make two configuration changes to your Visual Studio software to
build the wrapper.

1) edit the project properties - linker - input - additional dependencies
and change the path to those two LIB files to your local C: drive path to
the HDF library binaries. In my case it is C:\ HDF5-1.8.2\dll Note the
'dll' and not the 'lib' as came from the distribution.

2) edit the Tools - Options - Projects and Solutions - VC++ Directories -
Executable files and add the $(SystemRoot)\system32 to the list if it is not
already there.

John Huddleston, PhD, PE

  _____

From: Sebastian Good [mailto:sebastian@palladiumconsulting.com]
Sent: Thursday, December 18, 2008 6:18 PM
To: jhuddleston@hughes.net
Subject: Re: [hdf-forum] HDF .NET wrappers, x64

Hi John, thanks for writing. I have also been able to build the raw HDF
binaries with VS 2005 (using option (2) as you describe above also), but I
cannot successfully compile the HDF5DotNet wrapper project. Have you
experience with this?

Cheers,

Sebastian

On Thu, Dec 18, 2008 at 5:30 PM, John Huddleston <jhuddleston@hughes.net> wrote:

Sebastian,

The binaries from the hdfgroup are built with vs2005. I use vs2008 and have
successfully built them as well as the read_hdf and h4toh5 systems.

It takes knowledge of the Visual Studio libraries and how to include them in
the link line.

I installed the binary libraries under C:\ HDF4.2r3 and C:\ HDF5-1.8.2 and
then when linking you have two choices:

1) you can edit each project separately to add the LIB path; or

2) you can edit your project VC++ directories properties and add both
include and lib directories for all builds.

I did number 2, curious though, in the build the h4toh5 executables, I had
to exclude the LIBCMT.LIB library on a project by project basis.

John Huddleston, PhD, PE

  _____

From: Sebastian Good [mailto:sebastian@palladiumconsulting.com]
Sent: Thursday, December 18, 2008 12:10 AM
To: hdf-forum@hdfgroup.org
Subject: [hdf-forum] HDF .NET wrappers, x64

Hello HDF world--

I am working on compiling the .NET wrappers for HDF for the x64
architecture. Does anyone out there have experience building these wrappers,
whether in 32 bit mode or 64 bit mode? I would love to get in touch with
you.

Here is the problem I am having

The code downloaded from the HDF group (i.e. from
ftp://ftp.hdfgroup.uiuc.edu/pub/outgoing/hdf5/HDF5dotNetEnv/hdf5DotNet18.zip
) does not link against HDF binaries as provided, even on x86 (Win32).

There are a few DllExport issues which prevent the link, for instance:

1>H5O.obj : error LNK2001: unresolved external symbol "extern "C" int
__cdecl H5Oget_info(int,struct H5O_info_t *)"
(?H5Oget_info@@$$J0YAHHPAUH5O_info_t@@@Z)

Which can be fixed by putting the usual DllImport attribute on the relevant
function in H5O.cpp, i.e.

[DllImport("hdf5dll.dll",
           CharSet=CharSet::Auto,
           CallingConvention=CallingConvention::StdCall)]

There are a few of these. But once these are solved, 13 linking errors
related to the global ints H5P_CLS_XXX_g remain, e.g.

1>H5P.obj : error LNK2001: unresolved external symbol
__imp__H5P_CLS_OBJECT_CREATE_g

bindump and depends agree that these symbols are most certainly exported
from hdf5dll.dll as provided by the HDF group, so I can't tell what it's
complaining about. While one can never be sure, I think I've eliminated the
usual suspects (different run-time libraries, linking options, accidental
mixed 32 & 64 bit code generation, etc.).

(_HDF5USEDLL_is indeed defined in the HDF5DotNet project so that all the
functions and variable references which should be found in the external unit
are properly decorated with declspec(dllimport) in the wrapper library.)

Has anyone run into this sort of problem before?

Many many thanks for any advice.

Sebastian Good

Palladium Consulting

5

Sebastian,

You want to link to the "LIB" file under the HDF5-1.8.2/dll directory.

John

···

_____

From: Sebastian Good [mailto:sebastian@palladiumconsulting.com]
Sent: Saturday, December 20, 2008 2:31 PM
To: jhuddleston@hughes.net; hdf-forum@hdfgroup.org
Subject: RE: [hdf-forum] HDF .NET wrappers, x64

John,

Thanks again for writing. Adding the DLLs as a dependency instead of the LIB
files results in

1>C:\dev\bpa\src\Hdf-1.8\lib\x86\Release\hdf5dll.dll : fatal error LNK1107:
invalid or corrupt file: cannot read at 0x2A8

I've always linked to the lib files on the Windows platform, not the DLLs.
I'm certain I'm just neglecting one entirely obvious switch somewhere, but I
just don't know where!

Cheers,

Sebastian

From: John Huddleston [mailto:jhuddleston@hughes.net]
Sent: Friday, December 19, 2008 3:44 PM
To: 'Sebastian Good'; hdf-forum@hdfgroup.org
Subject: RE: [hdf-forum] HDF .NET wrappers, x64

Good afternoon Sebastian,

You have to make two configuration changes to your Visual Studio software to
build the wrapper.

1) edit the project properties - linker - input - additional dependencies
and change the path to those two LIB files to your local C: drive path to
the HDF library binaries. In my case it is C:\ HDF5-1.8.2\dll Note the
'dll' and not the 'lib' as came from the distribution.

2) edit the Tools - Options - Projects and Solutions - VC++ Directories -
Executable files and add the $(SystemRoot)\system32 to the list if it is not
already there.

John Huddleston, PhD, PE

  _____

From: Sebastian Good [mailto:sebastian@palladiumconsulting.com]
Sent: Thursday, December 18, 2008 6:18 PM
To: jhuddleston@hughes.net
Subject: Re: [hdf-forum] HDF .NET wrappers, x64

Hi John, thanks for writing. I have also been able to build the raw HDF
binaries with VS 2005 (using option (2) as you describe above also), but I
cannot successfully compile the HDF5DotNet wrapper project. Have you
experience with this?

Cheers,

Sebastian

On Thu, Dec 18, 2008 at 5:30 PM, John Huddleston <jhuddleston@hughes.net> wrote:

Sebastian,

The binaries from the hdfgroup are built with vs2005. I use vs2008 and have
successfully built them as well as the read_hdf and h4toh5 systems.

It takes knowledge of the Visual Studio libraries and how to include them in
the link line.

I installed the binary libraries under C:\ HDF4.2r3 and C:\ HDF5-1.8.2 and
then when linking you have two choices:

1) you can edit each project separately to add the LIB path; or

2) you can edit your project VC++ directories properties and add both
include and lib directories for all builds.

I did number 2, curious though, in the build the h4toh5 executables, I had
to exclude the LIBCMT.LIB library on a project by project basis.

John Huddleston, PhD, PE

  _____

From: Sebastian Good [mailto:sebastian@palladiumconsulting.com]
Sent: Thursday, December 18, 2008 12:10 AM
To: hdf-forum@hdfgroup.org
Subject: [hdf-forum] HDF .NET wrappers, x64

Hello HDF world--

I am working on compiling the .NET wrappers for HDF for the x64
architecture. Does anyone out there have experience building these wrappers,
whether in 32 bit mode or 64 bit mode? I would love to get in touch with
you.

Here is the problem I am having

The code downloaded from the HDF group (i.e. from
ftp://ftp.hdfgroup.uiuc.edu/pub/outgoing/hdf5/HDF5dotNetEnv/hdf5DotNet18.zip
) does not link against HDF binaries as provided, even on x86 (Win32).

There are a few DllExport issues which prevent the link, for instance:

1>H5O.obj : error LNK2001: unresolved external symbol "extern "C" int
__cdecl H5Oget_info(int,struct H5O_info_t *)"
(?H5Oget_info@@$$J0YAHHPAUH5O_info_t@@@Z)

Which can be fixed by putting the usual DllImport attribute on the relevant
function in H5O.cpp, i.e.

[DllImport("hdf5dll.dll",
           CharSet=CharSet::Auto,
           CallingConvention=CallingConvention::StdCall)]

There are a few of these. But once these are solved, 13 linking errors
related to the global ints H5P_CLS_XXX_g remain, e.g.

1>H5P.obj : error LNK2001: unresolved external symbol
__imp__H5P_CLS_OBJECT_CREATE_g

bindump and depends agree that these symbols are most certainly exported
from hdf5dll.dll as provided by the HDF group, so I can't tell what it's
complaining about. While one can never be sure, I think I've eliminated the
usual suspects (different run-time libraries, linking options, accidental
mixed 32 & 64 bit code generation, etc.).

(_HDF5USEDLL_is indeed defined in the HDF5DotNet project so that all the
functions and variable references which should be found in the external unit
are properly decorated with declspec(dllimport) in the wrapper library.)

Has anyone run into this sort of problem before?

Many many thanks for any advice.

Sebastian Good

Palladium Consulting