[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
20020214: netcdf 3.5.0 ncvarput failure - Cray SV1
- Subject: 20020214: netcdf 3.5.0 ncvarput failure - Cray SV1
- Date: Thu, 14 Feb 2002 15:07:03 -0700
John,
>Date: Thu, 14 Feb 2002 12:48:03 -0900
>From: John Metzner <address@hidden>
>Organization: Arctic Region Supercomputing Center
>To: Steve Emmerson <address@hidden>
>Subject: Re: 20020212: netcdf 3.5.0 ncvarput failure - Cray SV1
>Keywords: 200202122006.g1CK6Lx24308
The above message contained the following:
> I'm still working on trying to get netCDF 3.5.0 built and tested on
> our Cray SV1ex. I tried turning down the optimization level as you suggested
> to no avail, same error during 'make test'. This was done after a 'make
> distclean', making sure there was no config.cache and resetting the
> environment variables. There is one (that I know of) local change to the
> default library search path which causes /usr/local/lib to be prepended
> to the library search path (even prempting -L on the command line) which I
> pulled out. I ran through the full build & test sequence again and got the
> same error as below.
> I did pull the netCDF-3.5.0 package inside Cray Corporate, built and
> tested the package there on a SV1ex. It worked, so the problem is some local
> system change which is getting in the way.
> I pulled the package from Cray Corporate back out to the site with
> the "good" libraries and build products. I reran the 'make test' on it, again
> without error.
> Next I copied the locally built libsrc/libnetcdf.a and
> cxx/linetcdf_c++.a into the proper location for the "good" package from Cray
> Corporate. A 'make test' ran again without error. I was trying to determine
> if the problem was in the test code or the libraries built locally. Is that
> a valid test?
If your locally-built libnetcdf.a library, when copied into the Cray
Corporate package, results in that package correctly executing a "make
test", then it would seem that the problem lies in the building and/or
execution of the netCDF-2 test program rather than with the netCDF
library functions.
A good way to look at the differences in the build environments is to
use the "diff" utility on the file "macros.make", which is located in
the top-level source directory. Does it show anything significant?
Another thing to check is whether or not the files in the netCDF-2 test
directory, "nctest", are the same.
Regards,
Steve Emmerson <http://www.unidata.ucar.edu>