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.
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>