Peter, > Looks like not my luck day. > > I have tried downloaded the HDF5 1.8.11, but unfortunately the hdf5 wont > build with the Intel compilers. > It failed on some H5dump tests. I have attached the logs. The configure for HDF5-1.8.11 worked fine. I can't see what H5dump test failed in the files you attached, which seem to be for the netCDF-4.3.0 build rather than the HDF5-1.8.11 build. If you still have the log or details for that failure, could you send them? I also can't see the details of what went wrong in the netCDF-4.3.0 test, for which the apps3-build-netcdf-hdf5.1811.log just reports one failure in nc_test and says See nc_test/test-suite.log If you've still got that, could you send it? It's possible it is a bug in a test rather than the library code. --Russ > I am retrying this with HDF5 1.8.9. > > Peter > > -----Original Message----- > From: Unidata netCDF Support [mailto:address@hidden > Sent: 21 June 2013 18:00 > To: Chiu, Peter (STFC,RAL,RALSP) > Cc: address@hidden > Subject: [netCDF #JZT-105309]: neCDF 4.3.0 installation issue - Can't find or > link to the hdf5 library > > Peter, > > I'm happy to report that things work as they are supposed to with netCDF > 4.3.0 and hdf5-1.8.9, with these differences from what you are > doing: > > 1. When building HDF5, tell it where to find the szip library, but > don't specify --disable-shared, so it will build and install > both shared and static libraries. > > 2. Then, building netCDF-4.3.0, don't mention anything about the > location for where szip is installed in CPPFLAGS or LDFLAGS, > just where HDF5 is installed. The shared library is used in > preference to the static library, and it has information about > where to find szlib. When I tested this approach, everything > just worked. > > The moral is, it's more difficult to build and test static libraries than > shared libraries, and you have to make sure paths to all dependent libraries > are properly specified when building netCDF, even those you shouldn't have to > care about, such as szlib. For some reason, our configure script isn't > getting "-lsz" where it should when building with a static hdf5 library, and > the symptom is that it reports it can't find the hdf5 library. > > Shared libraries are easier for users to link against than static libraries > also. > > If there's some reason you must build only static libraries, such as that you > intend to support parallel I/O, then it would be easier if you install > dependent libraries such as libsz in the same directories you use for hdf5. > > (By the way, if you're going to be rebuilding netcdf-4.3.0 , I suggest using > the more recent hdf5-1.8.11, as it has some bug fixes and performance > improvements that affect netCDF-4.) > > Here's exactly what worked for me, to get a netCDF-4.3.0 shared library with > DAP support, netCDF-4 support, and ability to read szip-compressed files:: > > #!/bin/sh > SRCDIRS=/machine/russ/sources > INSTALLS=/machine/russ/installs > cd ${SRCDIRS}/szip-2.1 > SZDIR=${INSTALLS}/szip-2.1 > ./configure --prefix=${SZDIR} && make && make check install cd > ${SRCDIRS}/hdf5-1.8.9 H5DIR=${INSTALLS}/hdf5_189sz ./configure > --prefix=${H5DIR} --with-szlib=${SZDIR} && make check install cd > ${SRCDIRS}/netcdf-4.3.0 NCDIR=${INSTALLS}/nc430_hdf189sz > CPPFLAGS=-I${H5DIR}/include LDFLAGS=-L${H5DIR}/lib ./configure > --prefix=${NCDIR} && make check install > > --Russ > > Russ Rew UCAR Unidata Program > address@hidden http://www.unidata.ucar.edu > > > > Ticket Details > =================== > Ticket ID: JZT-105309 > Department: Support netCDF > Priority: Normal > Status: Closed > > Russ Rew UCAR Unidata Program address@hidden http://www.unidata.ucar.edu Ticket Details =================== Ticket ID: JZT-105309 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.