I have noticed that HDF4 has a dependency on an openssl library which I didn’t see a requirement for within the build examples. I’m using cmake to build it but I do not see any configuration option for specifying a custom location for the SSL libraries as I can for the JPEG and ZLIB libraries. Take a look at this abbreviated output of the ldd command from a RHEL8 virtual machine.
I think that is an indirect or “transitive” dependency, not a direct dependency of HDF4. You would control the openssl version through the package that depends on it directly, not through HDF4. Do you have a way of showing the full dependency stack for HDF4 on your RHEL8 virtual machine?
IMO packages should not be embedding transitive dependencies into dynamic libraries. Though not strictly prohibited, this is a holdover from static builds, and a bad habit.
We do not have a direct requirement for ssl. If you check the configuration files, you will see what is checked. It must be a dependency from a library somewhere else in the dependency tree.
Set the OPENSSL_ROOT_DIR in CMake to your OpenSSL path like cmake -DOPENSSL_ROOT_DIR=/custom/openssl/path. To build HDF4 without SSL check if there’s a CMake option to disable it. If not, custom script modifications might be required.
It looks like we have to explicitly set our library paths to cause HDF4 to link with the tirpc library now since something in HDF4 depends on RPC headers. On RHEL7 we did not have to do this.
Without executing these lines on RHEL8, we’ll get an error that the rpc headers can’t be found and linking errors for missing symbols.
$ENV:CPPFLAGS=“-I/usr/include/tirpc”
$ENV:LIBS=“-ltirpc”
Unfortunately, libtirpc is already pre-built for RHEL8 with a dependency on OpenSSL so unless I can find a way to avoid building those libraries I might not have any choice but to upgrade to OpenSSL1.1.1 and then deal with all of the downstream consequences of that.
I have determined that it is related to the ibtirpc.so. Is this RPC support a requirement to build HDF4? In the CMAKE configuration it looks like there is an option to disable that XDR support but when using the ./configure script I don’t see a way to disable linking with that.
It’s beginning to look as though I will be required to upgrade to openssl 1.1.1 or later in order to build this on RHEL8 because the build is dependent on the libtirpc installed to the system. That isn’t a library that we have ever build manually in the past.
I will try one more time to build with the OPENSSL_ROOT_DIR path set and possibly the LD_LIBRARY_PATH.
It looks like the cmake build outputs are substantially different than those produced when using the autoconf build system so I’ve chosen to continue working with the autoconf build system. Even the names of the lib and binary files are different when using cmake, but that is a different issue.
I thought that it was interesting how drastically different the ldd output looks building this on RH EL8 vs RHEL7.
RHEL7
ldd libdf.so
linux-vdso.so.1 => (0x00007ffcb89f4000)
libjpeg.so.8 => not found
libz.so => /lib64/libz.so (0x00007f84ae505000)
libc.so.6 => /lib64/libc.so.6 (0x00007f84ae137000)
/lib64/ld-linux-x86-64.so.2 (0x00007f84ae71b000)
I suppose that is a function of what the configure script is able to do when run on different operating system installations. If anyone has any tips on how I might be able to build this on a RHEL8 machine such that there are fewer dependencies I’d appreciate any ideas.
I haven’t yet figured out why with the same build instructions libtirpc is being linked in for the RHEL8 build, but not the RHEL7 build.
Try adding –disable-netcdf for configure, before building. Outside of configure, the only place in HDF4 source code with an RPC reference seems to be in the optional netcdf API support. This might also eliminate the libcrypto dependency.
To see only the direct dependencies, try objdump -p libdf.so | grep NEEDED (ref. ldd man page).
My earlier remark about including transitive dependencies was mistaken. ldd works much differently on Mac, with which I am more familiar. ldd on Linux locates and displays both direct and indirect dependencies.
HDF4 makes minimal use of XDR, which is probably where your dependencies are coming from. It’s mainly used for converting to big-endian, so you don’t need SSL, etc. If you build with --enable-hdf4-xdr you’ll build our XDR implementation, which has no dependencies.
Also, I’d highly recommend using HDF4 4.2.16 since we made a lot of improvements to the library in that release.
That seems to have worked! However the configure documentation states this:
–enable-hdf4-xdr Build xdr library from code in HDF4 source. Not supported for 64 bit mode.
I am building a 64 bit application and the ldd output seems to imply that the SW was successfully built as 64 bit so I am not clear about what the comment in the configure documentation means.
The good news is that there is no longer a libcrypto or libtirpc dependency any longer.
ldd …/hdf4-4.2.15-install/gcc12/debug/lib/libdf.so
linux-vdso.so.1 (0x00007ffc397db000)
libjpeg.so.62 => /lib64/libjpeg.so.62 (0x00007fc877749000)
libz.so.1 => /lib64/libz.so.1 (0x00007fc877531000)
libc.so.6 => /lib64/libc.so.6 (0x00007fc87716c000)
/lib64/ld-linux-x86-64.so.2 (0x00007fc8779b2000)
I did try that but with “–enable-netcdf=no”. Unfortunately, the configure script failed with a message that it was still unable to find rpc headers. There isn’t a --disable-netcdf option so I assume that the --enable-netcdf=no option is what I need to do to disable that.
As I mentioned before, I highly advise updating to the latest version. 4.2.16 has a lot of build system improvements over 4.2.15.
The “HDF4 XDR doesn’t work on 64-bit systems” message is incorrect and was removed in 4.2.16.
The --enable-netcdf functionality is mainly about name mangling to avoid conflicts with an installed version of netCDF. We still build the netCDF interface.
I’m hoping to remove XDR in the future. That probably won’t make it into the next release in February 2024, though.
