Closed alaniwi closed 4 years ago
lrose-core now no longer requires specific versions of HDF5 and NetCDF. The system-installed packages are now sufficient. See the latest release at: https://github.com/NCAR/lrose-core/releases/tag/lrose-core-20191213 Thanks Mike
Trying to build lrose-core on a system which has hdf5-devel 1.10.1 installed from a bespoke RPM (and which can't be upgraded because of other unrelated packages that depend on it), it fails with the following error.
in
run-configure.log
:and in
config.log
:The shared object file does exist, at
/tmp/lrose_build/scratch/lib/libhdf5_cpp.so.103
, suggesting thatLD_LIBRARY_PATH
was not set to point to it when performing this test. (In this case, the shared library from the bespoke RPM has a different version number, namely/usr/lib64/libhdf5_cpp.so.101
.)This also suggests to me that in situations where the build presumably works for people who build it on systems which have the hdf5-devel RPM installed from EPEL, then it must be because the dynamic linker is finding
/usr/lib64/libhdf5_cpp.so.103
, because if it wasn't then other people would already have been getting a similar error to the one I describe above.If my logic here is correct, then it would imply that the build is intended to use a private copy of hdf5 (under the
scratch/lib
directory) but in fact also relies on a system-wide installation containing a shared library with the same.so
version number (under/usr/lib64
). It needs to do one or other, not a mixture of the two. Aside from my build problems on a system with an older hdf5, it looks dangerous to compile against one copy of a library but then dynamically link to a different copy at run-time.