[netCDF #HLL-705129]: netcdf-4.3.2 build fail

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