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.
>Keywords: 199503211819.AA28912 Hi, > I'm having problems with netCDF under Solaris. My config.status is included > at the end of this message. I've checked your config.status file and it looks fine. It matches exactly what is generated here on our Solaris 2.3 platform except for the pathnames derived from the --prefix argument you gave to configure. > I'm having problems getting netcdf things to work under the Solaris platform. > I have applied both patches 3 and 4 to my netcdf-232pl2 distribution, > running configure and remaking the distribution between each. > > 88 12:40 patch < 2.3.2-patch3 > 91 12:42 configure --prefix=/home/dachshund/users/fraley/netcdf\ > /netcdf-232pl2/dist > 92 12:43 make all > & ! log & > 93 12:43 tail -f log > 96 12:49 patch < 2.3.2-patch4 > 97 12:50 configure --prefix=/home/dachshund/users/fraley/netcdf/\ > netcdf-232pl2/dist > 98 12:50 make all > & ! log2 & > 99 12:50 tail -f log2 There is no need to run `make' between applying patches 3 and 4. You should be able to apply patch4 immediately after applying patch3 and then run the `configure' and `make all' steps. You should also verify that you didn't get any errors when invoking `patch'. You haven't said what directory you are running `patch' from, but to be consistent with the --prefix you are giving `configure', I assume all the commands above, including the `patch' commands, are being invoked from within the directory you just patched: /home/dachshund/users/fraley/netcdf/netcdf-232pl2/dist This is important, because below you indicate a different problem (compiling the C++ interface) that can be explained by your changing to the wrong directory before you run a `make' command. > >>>>>>>>>>>>>>>>>>>>>> > Here is my environment: > >>>>>>>>>>>>>>>>>>>>>> > > acs:ridgeback-> uname -a > SunOS ridgeback 5.3 Generic_101318-41 sun4m sparc > > acs:ridgeback-> cc -V > cc: SC3.0 15 Dec 1993 > > acs:ridgeback-> CC -V junk.cc > CC: SC3.0 15 Dec 1993 > ccfe: SC3.0 15 Dec 1993 C++4.0 Ours is the same except for the C and C++ compiler versions: cc: SC3.0.1 13 Jul 1994 CC: SC3.0.1 13 Jul 1994 ccfe: SC3.0.1 13 Jul 1994 C++4.0.1 > >>>>>>>>>>>>>>>>>>>>>> > Here is the testing error I get... > >>>>>>>>>>>>>>>>>>>>>> > > *** Testing ncdimdef ... ok *** > *** Testing ncdimid ... ok *** > *** Testing ncdiminq ... ok *** > *** Testing ncdimrename ... ok *** > *** Testing ncvardef ... *** test_ncvardef: unwritten short > not FILL_SHORT > *** test_ncvardef: unwritten long not FILL_LONG > *** test_ncvardef: unwritten float not FILL_FLOAT > *** test_ncvardef: unwritten double not FILL_DOUBLE > *** test_ncvardef: unwritten double not FILL_DOUBLE > FAILED! *** > *** Testing ncvarid ... ok *** > *** Testing ncvarinq ... ok *** > *** Testing ncvarput1 ... ok *** > *** Testing ncvarget1 ... ok *** I assume this is an excerpt from the output of running `make test' after the last `make all' command above finished, and from the same (.../netcdf-232pl2/dist/) directory. I also assume no compiler or link errors were encountered from the `make all' except multiple occurrences of the ignorable warnings: semantics of ">" change in ANSI C; use explicit cast and semantics of ">=" change in ANSI C; use explicit cast I also assume the `test_ncvardef: unwritten short not FILL_SHORT' you saw is the *first* error message produced by `make test', and in particular you don't see any earlier errors with the XDR test, the netCDF formatted test, or the netCDF binary test. If any of these assumptions are wrong, please let us know, because otherwise our conclusions might be incorrect. We don't see the errors you saw when running `make test', but get instead: making `test' in directory /a/zero/home/russ/build/netcdf-232pl2/xdr cc -c -I/usr/include/rpc -DNDEBUG -O xdrtest.c cc -O xdrtest.o xdr.o xdrfloat.o xdrstdio.o xdrarray.o -o xdrtest ./xdrtest > xdrtest_out.new diff xdrtest_out.new testout.sav *** XDR passes formatted test *** cmp test.xdr test_xdr.sav *** XDR passes binary test *** returning to directory /a/zero/home/russ/build/netcdf-232pl2 making `test' in directory /a/zero/home/russ/build/netcdf-232pl2/libsrc cc -c -DNDEBUG -O cdftest.c ar rcuv libnetcdf.a array.o attr.o cdf.o dim.o file.o iarray.o error.o globdef.o putget.o putgetg.o sharray.o string.o var.o xdrposix.o cc -O cdftest.o libnetcdf.a -o cdftest ./cdftest > cdftest_out.new diff cdftest_out.new testout.sav *** netCDF passes formatted test *** cmp test.cdf test_cdf.sav *** netCDF passes binary test *** returning to directory /a/zero/home/russ/build/netcdf-232pl2 making `test' in directory /a/zero/home/russ/build/netcdf-232pl2/nctest ./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 ... ok *** *** Testing ncvargetg ... ok *** *** 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 *** Unless it's a bug we don't remember seeing in the earlier version of the Solaris compiler/libraries you are using, we can't explain the discrepancy. We no longer have any access to the 3.0 version of the C compiler, so we can't test whether that is the problem. If you could run `make distclean' to start again with a clean (patched) distribution, then send us the *complete* output from running `configure', and `make all test' from the same directory, we might be able to see something else that would explain this puzzling problem. No one else has reported this problem on Solaris 2.3, and several users have successfully built and are using netCDF on that platform. > >>>>>>>>>>>>>>>>>>>>>> > I can't even *compile* the C++ stuff, I'd like to use "CC" > >>>>>>>>>>>>>>>>>>>>>> > > acs:ridgeback-> pwd > /home/dachshund/users/fraley/netcdf/netcdf-232pl2/c++ Above, you indicate that the patched version is in /home/dachshund/users/fraley/netcdf/netcdf-232pl2/dist If that's the case, it looks like you are in the wrong directory to be running this test from. The patches are *required* for the C++ interface. If you run this from the patched version, "CC" should work fine, so it looks like you should have run this from /home/dachshund/users/fraley/netcdf/netcdf-232pl2/dist/c++ instead, and then you wouldn't have seen these compiler errors: > acs:ridgeback-> make > CC -g -I../dist/include -c netcdf.cc > "ncvalues.hh", line 20: Error: Multiple declaration for ncbyte. > ... Also, the "-I../dist/include" that appears above could only have come from a manually modified Makefile, since the c++/Makefile in netcdf 2.3.2 uses `-I../libsrc' instead. The former would only work after a `make install' had been done from the *patched* distribution. ______________________________________________________________________________ Russ Rew UCAR Unidata Program address@hidden P.O. Box 3000 http://www.unidata.ucar.edu/ Boulder, CO 80307-3000 ______________________________________________________________________________