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

Re: netCDF-3 compatability issues

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