[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
971117: compiling netcdf on VPP 300
- Subject: 971117: compiling netcdf on VPP 300
- Date: Mon, 17 Nov 97 11:29:13 -0700
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>