2015-02-10 21:50


  • c
  • hdf5
  • mingw

I am using go-hdf5 to read an hdf5 file into golang. I am on windows7 using a pretty recent copy of mingw and hdf5 1.8.14_x86 and it seems like trying to use any of the predefined types doesn't work, let's focus for example on T_NATIVE_UINT64. I have reduced the issue to the following, which basically leaves go-hdf5 out of the problem and points at something quite fundamental going wrong:

package main

 #cgo CFLAGS: -IC:/HDF_Group/HDF5/1.8.14_x86/include
 #cgo LDFLAGS: -LC:/HDF_Group/HDF5/1.8.14_x86/bin -lhdf5 -lhdf5_hl
 #include "hdf5.h"

 #include <stdio.h>

 void print_the_value2() { printf("the value of the constant is %d
", H5T_NATIVE_UINT64); }
import "C"

func main() {

You obviously need to have hdf5 and point the compiler at the headers/dlls and running go get, then executing prints this on my pc

the value of the constant is -1962924545

Running variations of the above, in how/where the constant is read, will give different answers for the value of H5T_NATIVE_UINT64. However I am pretty sure that is none are the right value and in fact trying to use a type with the id returned doesn't work, unsurprisingly.

If I write and run a "real" C program, I get different results

#include <stdio.h>
#include "hdf5.h"

hid_t _go_hdf5_H5T_NATIVE_UINT64() { return H5T_NATIVE_UINT64; }

int main()
    printf("the value of the constant is %d", _go_hdf5_H5T_NATIVE_UINT64());

Compiling using

C:\Temp>gcc -IC:/HDF_Group/HDF5/1.8.14_x86/include -LC:/HDF_Group/HDF5/1.8.14_x86/bin -lhdf5 -lhdf5_hl -o stuff.exe stuff.c

and running gives me

the value of the constant is 50331683

And that appears to be the right value as I can use it directly from my go program. Obviously I want to be able to use the constants instead. Any idea why this could be happening?

Extra info following comments below:

I looked for the definition of H5T_NATIVE_UINT64 in the hdf5 headers and see the following

c:\HDF_Group\HDF5\1.8.14_x86\include>grep H5T_NATIVE_UINT64 *
H5Tpkg.h:H5_DLLVAR size_t H5T_NATIVE_UINT64_ALIGN_g; 
H5Tpublic.h:#define H5T_NATIVE_UINT64 (H5OPEN H5T_NATIVE_UINT64_g)
H5Tpublic.h:H5_DLLVAR hid_t H5T_NATIVE_UINT64_g;

The whole header is here



  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享
  • 邀请回答


  • dtid30526 dtid30526 6年前

    H5T_NATIVE_UINT64 is NOT a constant but a #define that ultimately evaluates to (H5Open(), H5T_NATIVE_UINT64_g), which cgo does not understand.

    It's easy to check by turning on debug output on gcc's preprocessor:

    gcc -E -dM your_test_c_file.c | grep H5T_NATIVE_UINT64


    #define H5T_NATIVE_UINT64 (H5OPEN H5T_NATIVE_UINT64_g)

    Now the same for H5OPEN:

    gcc -E -dM test_go.c | grep '#define H5OPEN'


    #define H5OPEN H5open(),

    Right now, cgo does understand simple integer constant defines like #define VALUE 1234, or anything that the gcc preprocessor will turn into an integer constant. See the function func (p *Package) guessKinds(f *File) in $GOROOT/src/cmd/cgo/gcc.go.

    点赞 评论 复制链接分享