970326: netCDFPerl compilation (solaris)

Robert,

>Date: Thu, 27 Mar 1997 08:34:25 -0800 (PST) 
>From: Robert DeLoura <address@hidden>
>Organization: NOAA/PMEL
>To: address@hidden
>Subject: Re: 970326: netCDFPerl compilation (solaris) 
>Keywords: 199703270013.RAA26294

In the above message, you wrote:

> > It appears that the netCDF header file `/usr/local/include/netcdf.h'
> > doesn't define the type `nclong'.  This is, of course, impossible.
> 
> Well, I guess at government research facilities, we must do the impossible
> on a regular basis.  :-)  There's no definition for 'nclong' in our copy of
> '/usr/local/include/netcdf.h'.  There's an 'ncvoid' defined within an
> #ifndef statement, but no 'nclong'.
> 
> But just *asking* me that question has helped a little bit.  I've been 
> suspicious of our /usr/local installation of Netcdf, since there also
> appears to be one in /opt.  I think the /usr/local version is out of date,
> and the /opt one is more current.  There is an '/opt/include/netcdf.h; file
> in that *does* define 'nclong'.  Yet when I include the /opt directories
> in Perl compilation, the *Perl* compilation fails.  (Yes, I know that's not
> your problem.  :) )   

Based on the above, I would try to build the netCDFPerl package using
something like the following (NOTE: I use the bash(1) shell):

    $ make distclean
    ...
    $ CPP_NETCDF=-I/opt/include ./configure &>configure.log
    $ make &>all.log
    $ more all.log
    $ make test &>test.log
    $ more test.log
    $ make install &>install.log
    $ more install.log
    $ make clean

The key points are makeing a clean distribution and setting CPP_NETCDF.

> 
> > What version of the netCDF package do you have?
> 
> I wish I knew how to tell.

Look at the top of /opt/include/netcdf.h -- it'll have a version number.
The latest netCDF 2 release is the following:

    /* "$Id: netcdf.h,v 2.4 1996/04/12 16:51:15 russ Exp $" */

> I'm aware that we need 2.3.2 patch level 4 or
> later... what sort of errors am I likely to get if I have the wrong version?

I'd expect problems with `nclong'.  Here's some other, possibly
relevant stuff from the netCDF release notes:

    ------ Fri 9 Aug 1996  Changes in netCDF (2.4.2 to 2.4.3)

    Added the `-p fdigs,ddigs' option to ncdump.  This replaces and
    behaves like the (now deprecated and undocumented) `-d' option,
    except that it overrides any values specified by the `C_format'
    attribute for float or double values.

    Made precisions specified by the `-p' or (now deprecated) `-d'
    options apply to float or double attributes as well as data values.

    Fixed cause of potential overflow in ncdump when doing fuzzy
    comparison with fill value.  This might occur when comparing values
    near -FLT_MAX with a fill value near FLT_MAX, or similarly for
    doubles.

    Ported configuration mechanism to IRIX64 6.2 and GNU make(1) 3.74.

    Made generation of position-independent code the default.

    Adapted XDR test program to systems whose <float.h> doesn't define
    FLT_EPSILON and DBL_EPSILON.

    ------ Thu 2 May 1996 Changes in netCDF (2.4.1 to 2.4.2)

    Ported to an Intel 386-based, BSD/OS 2.1 system (but with no FORTRAN
    support).

    Changed XDRing of floating-point attributes to use xdr_floats() and
    xdr_doubles() so that transformations on a CRAY will always use the
    IEG functions when appropriate.  This works around a CRAY problem
    where, for some values, xdr_float() doesn't result in the same bit
    pattern as the IEG routines.

    Fixed an ncgen bug in generating the proper value for a scalar
    character variable initialized from a string in a CDL file.

--------
Steve Emmerson   <address@hidden>