[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[netCDF #BFM-570963]: errors with HDF5 library check when running "make check"



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