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

Re: netCDF-3 compatability issues

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.

  • Subject: Re: netCDF-3 compatability issues
  • Date: Fri, 01 Aug 1997 14:31:01 -0600
Hi Mark,

> After I read this in the netcdf-3.3 COMPATABILITY file,
> 
>   It is not necessary to rewrite programs that use the version 2
>   interface, because the netCDF-3 library includes a backward
>   compatibility interface that supports all the old functions,
>   globals, and behavior.
> 
> I thought that precompiled code would continue to work, and installed
> the netcdf-3.3.1 libs last night. However, this morning many users are 
> reporting this error,
> 
>   NCCRE: bad flag, did you forget to include netcdf.inc?: Invalid argument
> 
> on their code that "worked yesterday" :-). I tracked it down, and it
> appears that some of the symbols in the include files (netcdf.h and
> netcdf.inc) have taken on new values. So it seems all pre-exiting
> binaries are broken and need to be rebuilt. Is this true? Is there any 
> workaround, or do I need to start passing out bullets (for the user's
> to bite, and two for me).

Oops.

Precompiled code would continue to work if it was statically linked to
the old libraries.

But, yes, I'm afraid we only attempted to achieve backward compatibility
with recompiled source, not for binaries.  We should have been more
explicit about this in the COMPATIBILITY file you mention, and will fix
it before the next release.  One workaround is to re-install the
netCDF-3 libraries and include files in a different place than the
netCDF-2 libraries and include files, and let users recompile at their
own pace.

The C interface is *almost* binary-compatible; if you run the 2.4.3
nctest objects linked against the new libraries, the resulting test only
fails in a couple of minor places.  The same test on the FORTRAN
interface (linking the fortran/ftest.o file against the netCDF 3.3.x
library) fails in more places, in particular in creating new files with
NCCRE).

> One thought I had -- many of the existing apps use the shared version
> of the library, libnetcdf.so, which (rightly or wrongly) has also been 
> placed in /usr/lib/libnetcdf.so. So, I think I could leave the old
> v2.4 lib in there, and direct new compiles to link in the new v3.3.1
> library in /usr/local/lib/libnetcdf.so (via -L and -R switches in
> Solaris). 

Yes, that *should* work.  Please let us know if it doesn't.

--Russ