[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[netCDF #BFM-570963]: errors with HDF5 library check when running "make check"
- Subject: [netCDF #BFM-570963]: errors with HDF5 library check when running "make check"
- Date: Mon, 29 Mar 2010 16:28:04 -0600
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