971117: compiling netcdf on VPP 300

Peter,

> From: P M Oliver <address@hidden>
> Subject: compiling netcdf on VPP 300
> Organization: DCI Systems & User Support Group, RAL
> Keywords: 199711141550.IAA06528 netCDF VPP 300

In the above message, you wrote:

> UNIX_System_V fuji 4.1 ES 2 F300 UXP/V
> 
> Hi,
> 
> I'm having problems compiling netcdf-3.3.1 on a vpp300.

Please pardon my ignorance, but what the heck is a vpp300?

> 
> Here's the output from ./configure
> 
> loading cache ./config.cache

Just FYI, the "loading" in the above line means that the configure
script will use some values that it determined from a previous
execution.  These values are marked by "(cached)" in the output.  In
order to run the configure script "from scratch" you have to ensure that
the file "config.cache" does *not* exist before executing the configure
script.

> checking for m4... (cached) m4
> checking user-defined C compiler "vcc -DsunFortran"
> checking C compiler... works
> checking how to make dependencies... false
> checking for CC... no
> checking for cxx... no
> checking for c++... no
> checking for g++... no
> checking for gcc... no
> checking how to run the C preprocessor... (cached) cc -E
> checking user-defined FORTRAN compiler "frt"... works
> checking for FORTRAN .F compiler... 
> checking if FORTRAN compiler handles *.F files... yes
> checking for C-equivalent to FORTRAN routine "SUB"... sub_
> checking for FORTRAN "byte"... yes
> checking for FORTRAN "integer*2"... yes
> checking if FORTRAN "byte" is C "signed char"... yes
> checking if FORTRAN "byte" is C "short"... no
> checking if FORTRAN "byte" is C "int"... no
> checking if FORTRAN "integer*2" is C "short"... yes
> checking if FORTRAN "integer*2" is C "int"... no
> checking if FORTRAN "integer" is C "int"... yes
> checking if FORTRAN "real" is C "float"... yes
> checking if FORTRAN "doubleprecision" is C "double"... yes
> checking for FORTRAN-equivalent to netCDF "byte"... byte
> checking for FORTRAN-equivalent to netCDF "short"... integer*2
> checking for math library
> checking for -lc... (cached) no
> checking for -lm... (cached) yes
> checking for ar... (cached) ar
> checking for ranlib... (cached) :
> checking for stdlib.h... (cached) yes
> checking for sys/types.h... (cached) yes
> checking for strerror... (cached) yes
> checking for ftruncate... (cached) yes
> checking for st_blksize in struct stat... (cached) yes
> checking whether cross-compiling... (cached) no
> checking for IEEE floating point format... yes
> checking for ANSI C header files... (cached) yes
> checking for size_t... (cached) yes
> checking for off_t... (cached) yes
> checking for ssize_t... (cached) no
> checking for ptrdiff_t... (cached) yes
> checking for uchar... (cached) no
> checking whether char is unsigned... (cached) no
> checking whether byte ordering is bigendian... (cached) yes
> checking size of short... (cached) 2
> checking size of int... (cached) 4
> checking size of long... (cached) 4
> checking size of float... (cached) 4
> checking size of double... (cached) 8
> checking size of off_t... (cached) 4
> checking size of size_t... (cached) 4
> checking for catman... no
> checking for makewhatis... no
> checking for manual-page index command... 
> checking binary distribution directory... /home/ftp/pub/binary/dummy_system
> creating ./config.status
> creating macros.make
> udcreating fortran/nfconfig.inc
> fortran/nfconfig.inc is unchanged
> creating libsrc/ncconfig.h
> libsrc/ncconfig.h is unchanged
> 
> 
> first error in 
> 
>         vcc -DsunFortran -c -O -I.  -DNDEBUG ncio.c
> "/usr/include/unistd.h", line 104: error: too many same data types 
> specified for declaration of `(noname)'

Ouch!  The above looks like a problem with your compiler environment.
What does your systems administrator say about this problem?

> 
> I therefore commented out 
> 
> #include <unistd.h>
> 
> in posixio.c
> 
> All fine

Amazing!  Be advised that just because ncio.c compiled without the
<unistd.h> header, it still might not work without it.  This is because
the C compiler will assume that undeclared (but used) functions will
return an "int"; whereas, they might actually return something that
isn't.

> except the following warning on many lines
> 
> ncx.c", line 1231: warning: floating point constant `3.40282347e+38' is 
> out of range of `float'

Interesting.  That constant was carefully chosen to be a valid
floating-point value on IEEE systems (which, apparently, the vpp300
is).  I note, however, that FLT_MAX on our SunOS 5.6 system is
3.402823466E+38F -- a slightly smaller value.  One possible cause for
the warning is that the vcc compiler uses an algorithm for converting
a decimal floating-point value into a binary one that is slightly
different than that of most IEEE machines.

I suggest manually modifying the file libsrc/ncx.h: change the line

    #define X_FLOAT_MAX     3.40282347e+38f

to

    #define X_FLOAT_MAX     3.402823466e+38f

or even

    #define X_FLOAT_MAX     3.40282346e+38f

and excute the command "make" in the libsrc/ directory.  Does the
warning dissapear?

I've CC'ed the developer of the netCDF package in case he has any
comments on this.

> 
> When I then make the tests using "sunFortran" as UXPV is based on SUN I 
> believe I get the following error
> 
> 
>         ./nctest
> *** Testing nccreate ...        ok ***
> *** Testing ncopen ...          ok ***
> *** Testing ncredef ...         ok ***
> *** Testing ncendef ...         ok ***
> *** Testing ncclose ...         ok ***
> *** Testing ncinquire ...       ok ***
> *** Testing ncsync ...          ok ***
> *** Testing ncabort ...         ok ***
> *** Testing ncdimdef ...        ok ***
> *** Testing ncdimid ...         ok ***
> *** Testing ncdiminq ...        ok ***
> *** Testing ncdimrename ...     ok ***
> *** Testing ncvardef ...        ok ***
> *** Testing ncvarid ...         ok ***
> *** Testing ncvarinq ...        ok ***
> *** Testing ncvarput1 ...       ok ***
> *** Testing ncvarget1 ...       ok ***
> *** Testing ncvarput ...        ok ***
> *** Testing ncvarget ...        ok ***
> *** Testing ncvarputg ...       *** test_ncvarputg: ncvarputg should fail 
> for non-positive stride

Interesting!  Would you please go into the libsrc directory, execute
the following test program, and send me the output:

    #include <stddef.h>
    #include "ncx.h"

    void
    main()
    {
        ptrdiff_t   stride = -1;

        puts((unsigned long)stride >= X_INT_MAX
                ? "(unsigned long)(ptrdiff_t)-1 >= X_INT_MAX"
                : "(unsigned long)(ptrdiff_t)-1 < X_INT_MAX");
    }

It should print the first string.

> *** Testing ncvargetg ...       *** test_ncvargetg: ncvargetg should fail 
> for non-positive stride
> *** Testing ncrecinq ...        ok ***
> *** Testing ncrecput ...        ok ***
> *** Testing ncrecget ...        ok ***
> *** Testing ncvarrename ...     ok ***
> *** Testing ncattput ...        ok ***
> *** Testing ncattinq ...        ok ***
> *** Testing ncattget ...        ok ***
> *** Testing ncattcopy ...       ok ***
> *** Testing ncattname ...       ok ***
> *** Testing ncattrename ...     ok ***
> *** Testing ncattdel ...        ok ***
> *** Testing nctypelen ...       ok ***
>         cmp testfile.nc testfile_nc.sav
> testfile.nc testfile_nc.sav differ: char 2345, line 6
> *** Error code 1 (bu21)
> 
> make: fatal error.
> *** Error code 1 (bu21)
> 
> make: fatal error.
> *** Error code 1 (bu21)
> 
> make: fatal error.
> 
> 
> Any suggestions ?
> 
> 
> Thanks
> 
> Pete
> 
> - --
> ###############################################################################
> #Dr. Peter Oliver     address@hidden   http:TBA                     #
> #Tele: +44 (0) 1235 445164                                                    
> #
> #DCI Systems & User Support Group, RAL, Chilton, Didcot, Oxfordshire, OX11 
> 0QX#
> ###############################################################################

--------
Steve Emmerson   <http://www.unidata.ucar.edu>