[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[netCDF #XHL-435207]: [netcdfgroup] netcdf.h declares non-existing functions



Heiko,

> since netcdf-4.1.2, the netcdf.h file declares all netcdf4 functions, 
> like nc_def_var_deflate and NC_NETCDF4, even if the library was compiled 
> without hdf5 support, and does not have these functions.
> 
> I have code like
> 
> #ifdef NC_NETCDF4
>    nc_def_var_deflate(...)
> #endif
> 
> which worked perfectly with netcdf3 and netcdf4 until 4.1.1. Since 
> netcdf 4.1.2, this code compiles still, but when the netcdf-library was 
> not compiled with hdf5 support, the code won't link with the library.
> This means, that netcdf since 4.1.2 has a single API, but has different 
> ABIs depending on netcdf-configure flags. I would suggest adding the 
> 'Extra netcdf4 stuff.' function calls to the netcdf3 code, even if they 
> are empty, e.g.
> 
> int
> nc_def_var_deflate(int ncid, int varid, int shuffle, int deflate,
>                     int deflate_level)
> {
>       return NC_NOERR;
> }
>
> This means, that netcdf since 4.1.2 has a single API, but has different 
> ABIs depending on netcdf-configure flags. I would suggest adding the 
> 'Extra netcdf4 stuff.' function calls to the netcdf3 code, even if they 
> are empty, e.g.
> 
> int
> nc_def_var_deflate(int ncid, int varid, int shuffle, int deflate,
>                     int deflate_level)
> {
>       return NC_NOERR;
> }

Sorry, but I can't duplicate the problem.  This is supposed to be
handled by the "dispatch layer" in netCDF-4.x.  For example, when you
run "make check" on a netCDF-4.2 distribution that has been configured
with "--disable-netcdf-4", it will link and run netCDF-3 tests against
the library, so this would indicate all the public functions declared in
netcdf.h must be implemented.

The following function appears in libdispatch/dvar.c, even when
configured with "--disable-netcdf-4":

int
nc_def_var_deflate(int ncid, int varid, int shuffle, int deflate, int 
deflate_level)
{
    NC* ncp;
    int stat = NC_check_id(ncid,&ncp);
    if(stat != NC_NOERR) return stat;
    return 
ncp->dispatch->def_var_deflate(ncid,varid,shuffle,deflate,deflate_level);
}

I've also just tried building the 4.2 library with --disable-netcdf-4
and --disable-shared, and verified that a netCDF-3 program compiles and
links with the resulting static library.  However, I had to remove
previously built shared libraries from the directory in which I
installed the static library, because the dynamic linker/loader will use
an older installed shared library in preference to a new static library.

I also built a new shared library with --disable-netcdf-4 but without
--disable-shared and verified that a netCDF-3 program could be
successfully linked and run against the resulting shared library.  For
this, I set LD_LIBRARY_PATH to run the resulting program, but other
alternatives would also work, assuming the library is installed in
LIBDIR:

   - add LIBDIR to the `LD_RUN_PATH' environment variable
     during linking
   - use the `-Wl,-rpath -Wl,LIBDIR' linker flag
   - have system administrator add LIBDIR to `/etc/ld.so.conf'

This was all on a Linux system, but our cross-platform tests should
catch such problems on some other systems, such as Solaris, MacOS, and
AIX.

It's possible I've misunderstood the problem.  If so, I'll need more
information to reproduce it.  For now, I think the dispatch layer
implementation already provides the stub functions for 'extra netCDF-4
stuff' that you're requesting ...

--Russ

Note: as Dennis Heimbigner pointed out last week, for now it's necessary 
to build netCDF-4.2 with "--disable-dap-remote-tests", at least until we 
resolve a problem with the test server, which was movedfrom port 8080 to 
8081.

Russ Rew                                         UCAR Unidata Program
address@hidden                      http://www.unidata.ucar.edu



Ticket Details
===================
Ticket ID: XHL-435207
Department: Support netCDF
Priority: Normal
Status: Closed


NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.