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.
Russ- there was a bug in the ncdump Makefile.am that was deleting some need files (like tst_ncml.c). So when you did a make distclean or make clean, these files were lost. It is corrected in the snapshot. =Dennis Russ Rew wrote: > New Staff Reply: errors with HDF5 library check when running "make check" > > Hi Mary, > >> More information: I unsetenv LD_LIBRARY_PATH and this made my build >> use my copy of the HDF5 libraries. I've attached the config.log if >> you're interested. >> >> >> I ran make check again, and had some problems. I've included the >> output from this. Do I need to be worried about these? > > I don't understand why a file included in the tar.gz distribution apparently > wasn't in the ncdump directory after you unpacked the tarball, as shown by > this part of the "make check" output: > >> *** creating tst_ncml.nc from tst_ncml.cdl >> can't open file ./tst_ncml.cdl for reading: >> No such file or directory >> FAIL: tst_output.sh > > When I unpack the 4.1.1-rc2 distribution, that file is in the ncdump > directory: > $ ls -l ncdump/tst_ncml.cdl > -rw-r--r-- 1 russ ustaff 209 Aug 9 2007 ncdump/tst_ncml.cdl > > Is it possible you ran out of disk space while unpacking the sources? > There's > another similar failure later on showing that the file > ncdump/tst_calendars.cdl > is missing, but it's in the ncdump directory after I unpack it: > $ ls -l ncdump/tst_calendars.cdl > -rw-r--r-- 1 russ ustaff 3732 Oct 26 2008 > ncdump/tst_calendars.cdl > > You may want to check that your downloaded copy of the rc2 tarball has the > same > size and MD5 signature as mine: > > $ ls -l netcdf-4.1.1-rc2.tar.gz; gmd5sum netcdf-4.1.1-rc2.tar.gz > -rw-rw-r-- 1 russ ustaff 11256880 Mar 23 13:03 > netcdf-4.1.1-rc2.tar.gz > 8869308b58de7a6c187ebf685cd8fb63 netcdf-4.1.1-rc2.tar.gz > > --Russ > >> --Mary >> >> On Mar 28, 2010, at 11:32 AM, Mary Haley wrote: >> >>> I think I see the issue with this. I *am* getting some system HDF5 >>> library, even though I have my own copy of it, and I specified the >>> path to it using >>> >>> ./configure --enable-netcdf-4 --enable-opendap --disable-f90 -- >>> disable-shared --with-hdf5=/contrib/ncl-5.2.0/external --with-zlib=/ >>> contrib/ncl-5.2.0/external --with-szlib=/contrib/ncl-5.2.0/external >>> --prefix=/contrib/ncl-5.2.0/external >>> >>> In the "make check" output, I see this kind of thing: >>> >>> libtool: link: gcc -fPIC -o tst_h_files tst_h_files.o -L/contrib/ >>> ncl-5.2.0/external/lib -L/usr/kerberos/lib ./.libs/libnetcdf.a / >>> contrib/ncl-5.2.0/external/lib/libcurl.a -lidn -lldap -lrt -lssl - >>> lcrypto -ldl /usr/local/hdf5-1.8.2/lib/libhdf5_hl.so /usr/local/ >>> hdf5-1.8.2/lib/libhdf5.so /contrib/ncl-5.2.0/external/lib/ >>> libhdf5_hl.a /contrib/ncl-5.2.0/external/lib/libhdf5.a /contrib/ >>> ncl-5.2.0/external/lib/libsz.a -lm -lz -Wl,-rpath -Wl,/usr/local/ >>> hdf5-1.8.2/lib -Wl,-rpath -Wl,/usr/local/hdf5-1.8.2/lib >>> >>> Note that "/usr/local/hdf5-1.8.2" somehow got in there, even though >>> I didn't point to this. >>> >>> I'm going to see if this is in my LD_LIBRARY_PATH. Perhaps this is >>> overriding my "--with-hdf5" setting? >>> >>> --Mary > > Russ Rew UCAR Unidata Program > address@hidden http://www.unidata.ucar.edu > > > > Ticket Details > =================== > Ticket ID: BFM-570963 > Department: Support netCDF > Priority: Normal > Status: Closed > Link: > https://www.unidata.ucar.edu/esupport/staff/index.php?_m=tickets&_a=viewticket&ticketid=10948 Ticket Details =================== Ticket ID: BFM-570963 Department: Support netCDF Priority: Normal Status: Closed