H5FDhttp.c build errors with v4.9.1

[dqwu]

This build issue is only reproducible with latest v4.9.1, not reproducible with v4.9.1-rc2.

Reproduced on ANL workstations (Ubuntu 20.04, gcc 9.4.0, mpich 3.3.2) with steps below.

[Build and install HDF5 1.14.0]

wget https://support.hdfgroup.org/ftp/HDF5/releases/hdf5-1.14/hdf5-1.14.0/src/hdf5-1.14.0.tar.gz
tar zxf hdf5-1.14.0.tar.gz
cd hdf5-1.14.0
CC=mpicc ./configure --prefix=/path/to/hdf5 --enable-parallel
make -j4
make install

[Build and install NetCDF-C 4.9.1]

wget https://github.com/Unidata/netcdf-c/archive/v4.9.1.tar.gz
tar zxf v4.9.1.tar.gz
cd netcdf-c-4.9.1
CC=mpicc CPPFLAGS="-I/path/to/hdf5/include" LDFLAGS="-L/path/to/hdf5/lib" ./configure --prefix=/path/to/netcdf
make -j4

Build errors:

H5FDhttp.c:166:5: error: initializer element is not computable at load time
...
H5FDhttp.c:172:5: error: incompatible types when initializing type 'enum H5F_close_degree_t' using type 'void *'
  172 |     NULL,                       /* sb_size      */
      |     ^~~~

[WardF]

We have not tested against HDF5 1.14 at all at this point; I recommend using hdf5 1.12.x. I tried building against hdf5 1.14 several weeks ago and ran into other, similar errors that we will take a look at during the next release cycle, after we get the next Fortran and C++ interface libraries released.

[hmaarrfk]

It seems like the structure changed between 1.12.2 and 1.14.0. I'm not sure why linux isn't seeing these problems.

• 1.12.2: https://github.com/HDFGroup/hdf5/blob/hdf5-1_12_2/src/H5FDpublic.h#L270
• 1.14.0: (develop) https://github.com/HDFGroup/hdf5/blame/develop/src/H5FDdevelop.h#L28

Untested hint toward a patch

diff --git a/libhdf5/H5FDhttp.c b/libhdf5/H5FDhttp.c
index 81dba1f5..f7d1f853 100644
--- a/libhdf5/H5FDhttp.c
+++ b/libhdf5/H5FDhttp.c
@@ -163,6 +163,7 @@ static herr_t H5FD_http_unlock(H5FD_t *_file);
 
 /* Beware, not same as H5FD_HTTP_g */
 static const H5FD_class_t H5FD_http_g = {
+    0x1,                        /* version */
     "http",                     /* name         */
     MAXADDR,                    /* maxaddr      */
     H5F_CLOSE_WEAK,             /* fc_degree    */
@@ -192,6 +193,10 @@ static const H5FD_class_t H5FD_http_g = {
     H5FD_http_get_handle,      /* get_handle   */
     H5FD_http_read,            /* read         */
     H5FD_http_write,           /* write        */
+    NULL,                      /* read_vector  */
+    NULL,                      /* write_vector */
+    NULL,                      /* read_selection  */
+    NULL,                      /* write_selection */
     H5FD_http_flush,           /* flush        */
     NULL, 		       /* truncate     */
     H5FD_http_lock,            /* lock         */

[edwardhartnett]

@WardF hdf5-1.14.0 has some really necessary and helpful HPC performance improvments and bug fixes. I strongly recommend that you start testing with it immediately, it's going to be a very popular release.

We are already using 1.14.0 at NOAA and it not only solves some mysterious and annoying MPI bugs, but it's significantly faster.

[edwardhartnett]

The workaround for this is to build with --disable-byterange.

[hmaarrfk]

The workaround for this is to build with --disable-byterange.

I'm not sure that this is true. The data structure looks very different between 1.12 and 1.14.

aren't the errors but the structure elements are of different data types?

[edwardhartnett]

When --disable-byterange is used, this section of code is not compiled, and the rest of netcdf-c will compile and pass tests. That's what I meant by workaround.

Of course, to get byterange working again will require some changes in the code. ;-)

[DennisHeimbigner]

From HDF5 web site (https://portal.hdfgroup.org/display/HDF5/Migrating+from+HDF5+1.12+to+HDF5+1.14):

For details, see the (soon to be released) 1.12 to 1.14. VFL Migration Guide.
For details, see the (soon to be released) 1.12 to 1.14. VOL Migration Guide.

We may have to wait until these documents are released.

[cponder]

What-all would I be giving up by using the --disable-byterange flag?
The description sounds like it's enabling rather then disabling a capability:

--disable-byterange     allow byte-range I/O

I'm building HDF5 & NetCDF to be used underneath PIO, however that may matter.