I encountered this issue just recently. We build HDF5 for our data analysis software by hand, on Scientific Linux 6. For a “standalone build” we would configure HDF5 like:
../hdf5-1.10.1/configure --prefix=/home/krasznaa/projects/hdf5/hdf5-1.10.1-install --with-zlib=/usr/include,/usr/lib64 --with-pthread=/usr/include,/usr/lib --enable-cxx --enable-hl --enable-threadsafe --enable-unsupported --enable-build-mode=production
By “standalone”, in this context I mean that we only pick up dependencies from the system (or from other components that we build ourselves). This is in contrast to the build we do against LCG releases. In which case the configuration command looks something like:
../hdf5-1.10.1/configure --prefix=/home/krasznaa/projects/hdf5/hdf5-1.10.1-install --with-zlib=/cvmfs/sft.cern.ch/lcg/releases/LCG_93/zlib/1.2.11/x86_64-slc6-gcc62-opt/include,/cvmfs/sft.cern.ch/lcg/releases/LCG_93/zlib/1.2.11/x86_64-slc6-gcc62-opt/lib --with-pthread=/usr/include,/usr/lib --enable-cxx --enable-hl --enable-threadsafe --enable-unsupported --enable-build-mode=production
I.e. in that case we take ZLIB from a central installation. (It’s a long story…)
Now, when I tell
configure to take ZLIB explicitly from
/usr/lib64, something very unfortunate happens. If we already have a version of HDF5 installed on the system (which would be under
/usr/lib64 as well), libraries in our build, which need
libhdf5.so themselves, end up linked against
[bash][pcadp02]:build > ldd -r ../hdf5-1.10.1-install/lib/libhdf5_cpp.so linux-vdso.so.1 => (0x00007ffe9f11f000) libhdf5.so.6 => /usr/lib64/libhdf5.so.6 (0x00007fa1da2eb000) librt.so.1 => /lib64/librt.so.1 (0x00007fa1da0e2000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fa1d9ec5000) libz.so.1 => /lib64/libz.so.1 (0x00007fa1d9caf000) ...
Which leads to these sort of warning when we later on try to use this
/cvmfs/sft.cern.ch/lcg/contrib/bintuils/2.28/x86_64-slc6/bin/ld: warning: libhdf5.so.6, needed by /build1/atnight/localbuilds/nightlies/21.2/build/install/AnalysisBaseExternals/21.2.25/InstallArea/x86_64-slc6-gcc62-opt/lib/libhdf5_cpp.so, may conflict with libhdf5.so.101
So… My questions are:
- Is the “configure” build still maintained, or is the development only focusing on the CMake style build by now?
- Was this issue known already?
- Could this behaviour be fixed? So that the HDF5 build would always pick up the libraries that it built just now for its own linking, and only take external libraries (pthreads and ZLIB) from somewhere else.
As far as I can see, this issue only affects the configure based build. The CMake build know how to link against the correct libraries. But for some technical reasons we’d like to rely on the configure based build for now.