This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
Hi Caleb, > I'm not sure if this is the right channel to report this, however I could > not find a submit issue or ticket link on the website. We do have a Jira site for reporting bugs, https://bugtracking.unidata.ucar.edu/browse/NCF/, but you currently need a login to create a new issue. > I am building the latest netcdf-4.3.2 C release from source with the > commands: > > CPPFLAGS=-I/home/ums/r1963/usr/include LDFLAGS=-L/home/ums/r1963/usr/lib > ./configure > make > > The make process fails with the following error: > > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I../include > -I/home/ums/r1963/usr/include -g -O2 -MT libnetcdf4_la-nc4internal.lo -MD > -MP -MF .deps/libnetcdf4_la-nc4internal.Tpo -c nc4internal.c -fPIC -DPIC > -o .libs/libnetcdf4_la-nc4internal.o > nc4internal.c:417: error: conflicting types for ‘nc4_rec_find_nc_type’ > ../include/nc4internal.h:351: error: previous declaration of > ‘nc4_rec_find_nc_type’ was here > > This is because in include/nc4internal.h nc4_rec_find_nc_type is declared > as *nc4_rec_find_nc_type(const NC_GRP_INFO_T *start_grp, hid_t > target_nc_typeid); > > and used in libsrc4/nc4internal.c as nc4_rec_find_nc_type(const > NC_GRP_INFO_T *start_grp, nc_type target_nc_typeid) I don't think that's ever been reported as an error or something that caused make to fail, possibly because both hid_t and nc_type are both typedefs for int currently. Nevertheless, it seems we should have at least seen a warning about the type mismatch. > when the second argument type is changed to hid_t the compilation succeeds > without any errors. Since all 10 of the invocations of nc4_rec_find_nc_type in libsrc4 have the second argument of type nc_type and the name of the function also uses nc_type, I think the correct fix would instead be to change the prototype declaration in include/nc4internal.h to use nc_type for the type of the second argument to the nc4_rec_find_nc_type function. In any case, thanks for reporting the problem. Your C compiler must be pickier than what we are testing with, which includes clang and the Coverity static checker. > Sorry if this has already been reported or dealt with. No problem, I haven't seen it mentioned previously. --Russ > > Thanks, > Caleb Robinson > > Russ Rew UCAR Unidata Program address@hidden http://www.unidata.ucar.edu Ticket Details =================== Ticket ID: HLL-705129 Department: Support netCDF Priority: Normal Status: Closed