build appears to provide its own copy of hdf5 while also depending on system-wide hdf5

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:

checking whether the C compiler works... configure: error: in `/tmp/lrose_build/lrose-core/codebase':
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.

and in config.log:

configure:3234: gcc   -I/tmp/lrose_build/scratch/include -I/tmp/lrose_build/scratch/include -DNO_JASPER_LIB -L/tmp/lrose_build/scratch/lib -Wl,--enable-new-dtags,-rpath,'$$ORIGIN/lrose-core_runtime_libs:$$ORIGIN/../lib:/tmp/lrose/lib:/tmp/lrose_build/scratch/lib' -L/tmp/lrose_build/scratch/lib -L/tmp/lrose_build/scratch/lib conftest.c  /tmp/lrose_build/scratch/lib/libhdf5_cpp.so /tmp/lrose_build/scratch/lib/libhdf5_hl.so /tmp/lrose_build/scratch/lib/libhdf5.so >&5
configure:3238: $? = 0
configure:3276: result: a.out
configure:3295: checking whether the C compiler works
configure:3305: ./a.out
./a.out: error while loading shared libraries: libhdf5_cpp.so.103: cannot open shared object file: No such file or directory

The shared object file does exist, at /tmp/lrose_build/scratch/lib/libhdf5_cpp.so.103, suggesting that LD_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.

NCAR / lrose-core

build appears to provide its own copy of hdf5 while also depending on system-wide hdf5 #77