ccr cannot be build with netcdf-c/4.9.3 - NC_HAS_NC4 is missing in netcdf_meta.h

[bzfbmsch]

Good evening, I am trying to build ccr (https://github.com/ccr/ccr) with netcdf/4.9.3. Running configure, it checks for NC_HAS_NC4. This variable is missing in netcdf_meta.h and configure stops.

nc-config tells me: --has-nc4 -> yes

As a test if my build of netcdf-c/4.9.3 is eventually incomplete, I have rebuild netcdf/4.9.2 with the same configure options like netcdf/4.9.3.

 ./configure --prefix=$NETCDF_ROOT \
        --enable-hdf5 \
        --enable-cdf5 \
        --enable-dap-long-tests \
        --enable-large-file-tests \
        --with-temp-large=$TEST_DIR \
        --enable-mmap \
        --enable-erange-fill \
        --disable-dap-remote-tests \
        --enable-nczarr \
        --enable-nczarr-filters \
        --enable-logging

For the 4.9.2-build the variable NC_HAS_NC4 is defined, for 4.9.3 it is not.

Is this an error in the 4.9.3 build or is ccr not ready for netcdf/4.9.3 yet? Should I eventually edit netcdf_meta.h and add NC_HAS_NC4?

Kind regards, Martin Schmidt

[czender]

Hi Martin, The supported codecs in CCR have been implemented in the default netCDF C-library (and fortran, and Java) and so development of CCR is on hiatus unless/until there is reason to develop or test new codecs. @edhartnett can further clarify. Ed, should we update CCR to ensure build-compatibility with netCDF-C 4.9.3 and 4.10.0? Martin, it looks like 4.9.3 replaced NC_HAS_NC4 with NC_HAS_HDF5, so I think the answer to your final question is Yes.

[edhartnett]

No there is no reason to build CCR, because all CCR filters have been successfully integrated into netcdf-c.

I do intend to use CCR for further compression work but not yet.

Thanks, Ed

On Tue, May 13, 2025 at 12:36 PM Charlie Zender @.***> wrote:

czender left a comment (Unidata/netcdf-c#3121) https://github.com/Unidata/netcdf-c/issues/3121#issuecomment-2877577228

Hi Martin, The supported codecs in CCR have been implemented in the default netCDF C-library (and fortran, and Java) and so development of CCR is on hiatus unless/until there is reason to develop or test new codecs. @edhartnett https://github.com/edhartnett can further clarify. Ed, should we update CCR to ensure build-compatibility with netCDF-C 4.9.3 and 4.10.0? Martin, it looks like 4.9.3 replaced NC_HAS_NC4 with NC_HAS_HDF5, so I think the answer to your final question is Yes.

— Reply to this email directly, view it on GitHub https://github.com/Unidata/netcdf-c/issues/3121#issuecomment-2877577228, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABCSXXF5OOK3JUTW73S7K5T26I3RLAVCNFSM6AAAAAB24CJ2DCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQNZXGU3TOMRSHA . You are receiving this because you were mentioned.Message ID: @.***>

[DennisHeimbigner]

The reason that NC_HAS_NC4 was changed to NC_HAS_HDF5 is because of the addition of zarr support to the netcdf-c library. We now have two separate subsystems (Zarr and HDF5) that share libsrc4. So it is now the case that NC_HAS_HDF5 => NC_HAS_NC4, the reverse is false.