Hi Neil. > I am trying to build netCDF 4.1.1 (without the netCDF 4 extension (HDF5 > etc.)) on a Pentium 4 machine running i686 CentOS release 5.4 (Final). > > I'm using the compiler flags "-march=pentium4 -mfpmath=sse > -malign-double -O3" for gcc, g++, and gfortran. (Changing O3 to O2 > didn't change the problem.) > > I am failing 1 (or 2) of 11 tests. The tests failed are tst_lengths.sh > and tst_nccopy3.sh. (However, tst_nccopy3.sh seems to fail only because > it is expecting files that would be created by tst_lengths.sh, and the > files don't exist because tst_lengths.sh didn't run to completion. If I > modify tst_lengths.sh so that it doesn't exit on each failure but echos > a diagnostic message, I get the following output (and tst_nccopy3.sh no > longer subsequently fails). We haven't seen the tst_lengths.sh test fail on any Unix platforms, only occasionally on Windows running cygwin, and it succeeds on our cygwin platform, so we've been unable to reproduce the problem here. I tried building with the "-mfpmath=sse -malign-double -O3" flags on our x86_64 Linux platform, but couldn't reproduce any of the errors you saw. The small.nc and small2.nc files you supplied are readable netCDF files. The small2.nc is what's expected, since it's the result of the last test run by tst_lengths.sh, which succeeded. The small.nc file has extra padding added to the end of what's expected in the file to make it 4096 bytes instead of the expected 68 bytes, but the netCDF library doesn't see those extra bytes when reading the file. So your library should work fine and you can install it, but it creates either larger files than expected with extra 0-byte padding for small netCDF files, or files slightly smaller than what are expected by truncating up to 3 bytes of expected padding when NOFILL is specified. Are you by any chance using an experimental file system or a file system configured in an unusual way? --Russ > Output from modified tst_lengths.sh: > *** testing length of classic file > *** testing length of classic file written with NOFILL > Expecting=>68, Measured=>65 > *** testing length of rewritten classic file > Expecting=>68, Measured=>4096 > *** testing length of rewritten classic file written with NOFILL > Expecting=>68, Measured=>4096 > *** testing length of 64-bit offset file > *** testing length of 64-bit offset file written with NOFILL > Expecting=>72, Measured=>69 > *** testing length of rewritten 64-bit offset file > Expecting=>72, Measured=>4096 > *** testing length of rewritten 64-bit offset file written with NOFILL > Expecting=>72, Measured=>4096 > *** testing length of one-record-variable classic file > *** testing length of one-record-variable classic file written with > NOFILL > *** testing length of one-record-variable 64-bit offset file > *** testing length of one-record-variable 64-bit offset file written > with NOFILL > FAIL: tst_lengths.sh > > 1. I am installing from netcdf-4.1.1.tar.gz downloaded from > http://www.unidata.ucar.edu/downloads/netcdf/netcdf-4_1_1/index.jsp. I > cannot find a VERSION file, but the date of the archive seems to be > 2010-04-12.1249. > > 2. The output from "./configure", "make", and "make check" are attached > as setup.log, make.log, and check.log respectively. > > <<make.log>> <<check.log>> <<setup.log>> > 3. The configure did not fail so I have not included config.log. > > 4. I get the same errors whether I enable or disable large file tests. > > === > > So I have two questions. 1) Does this file size discrepancy indicate a > major problem with my build? 2) If it is a problem, how best can I go > about resolving it? > > I am attaching for reference the small and small2 files that were > upsetting tst_lengths.sh in case they should be of interest. > > <<small.cdl>> <<small.nc>> <<small2.cdl>> <<small2.nc>> > Please let me know if any further information is required to > diagnose/resolve this issue. Russ Rew UCAR Unidata Program address@hidden http://www.unidata.ucar.edu Ticket Details =================== Ticket ID: LIC-415919 Department: Support netCDF Priority: Normal Status: Closed
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.