http://bugzilla.opensuse.org/show_bug.cgi?id=1055930 Bug ID: 1055930 Summary: science: Bug: cdo is not linked consistently to HDF5 Classification: openSUSE Product: openSUSE.org Version: unspecified Hardware: Other OS: Linux Status: NEW Severity: Normal Priority: P5 - None Component: 3rd party software Assignee: dmitry@roshchin.org Reporter: edward.baudrez@gmail.com QA Contact: opensuse-communityscreening@forge.provo.novell.com Found By: --- Blocker: --- `cdo` (Climate Data Operators) in the 'Science' repository is not being linked consistently to the HDF5 library. Just to be sure, I'm using the latest release of `cdo` from Science: # rpm -qi cdo Name : cdo Version : 1.8.2 Release : 2.1 Architecture: x86_64 Install Date: Friday 18 August 2017 11 h 48 min 19 s CEST Group : Productivity/Scientific/Other Size : 7869837 License : GPL-2.0 Signature : DSA/SHA1, Thursday 10 August 2017 15 h 24 min 03 s CEST, Key ID 01db7302943d8bb8 Source RPM : cdo-1.8.2-2.1.src.rpm Build Date : Thursday 10 August 2017 15 h 23 min 54 s CEST Build Host : lamb01 Relocations : (not relocatable) Vendor : obs://build.opensuse.org/science URL : https://code.zmaw.de/projects/cdo Summary : A program for manipulating GRIB/NetCDF/SERVICE/EXTRA/IEG files Description : CDO (Climate Data Operators) is a collection of command line Operators to manipulate and analyse Climate and NWP model Data. Supported data formats are GRIB 1/2, netCDF 3/4, SERVICE, EXTRA and IEG. There are more than 600 operators available. Distribution: science / openSUSE_Leap_42.2 It is linked, at the same time, to libnetcdf.so.11 and libhdf5.so.100 (the 1.10 series of HDF5): # readelf -d /usr/bin/cdo Dynamic section at offset 0x465cc8 contains 38 entries: Tag Type Name/Value 0x0000000000000001 (NEEDED) Shared library: [libxml2.so.2] 0x0000000000000001 (NEEDED) Shared library: [libMagPlus.so] 0x0000000000000001 (NEEDED) Shared library: [libcurl.so.4] 0x0000000000000001 (NEEDED) Shared library: [libproj.so.9] 0x0000000000000001 (NEEDED) Shared library: [libeccodes.so] 0x0000000000000001 (NEEDED) Shared library: [libudunits2.so.0] 0x0000000000000001 (NEEDED) Shared library: [libnetcdf.so.11] 0x0000000000000001 (NEEDED) Shared library: [libhdf5_hl.so.100] 0x0000000000000001 (NEEDED) Shared library: [libhdf5.so.100] 0x0000000000000001 (NEEDED) Shared library: [libsz.so.2] 0x0000000000000001 (NEEDED) Shared library: [libm.so.6] 0x0000000000000001 (NEEDED) Shared library: [libgomp.so.1] 0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] [irrelevant entries stripped] Again, I am using the proper version of libnetcdf.so.11 from Science: # rpm -qi libnetcdf11 Name : libnetcdf11 Version : 4.4.1 Release : 30.4 Architecture: x86_64 Install Date: Tuesday 13 June 2017 09 h 35 min 50 s CEST Group : System/Libraries Size : 1768648 License : NetCDF Signature : DSA/SHA1, Saturday 10 June 2017 11 h 36 min 15 s CEST, Key ID 01db7302943d8bb8 Source RPM : netcdf-4.4.1-30.4.src.rpm Build Date : Saturday 10 June 2017 11 h 35 min 51 s CEST Build Host : lamb22 Relocations : (not relocatable) Vendor : obs://build.opensuse.org/science URL : http://www.unidata.ucar.edu/software/netcdf/ Summary : Shared libraries for the NetCDF scientific data format [rest of the output stripped] However, libnetcdf.so.11 is linked against libhdf5.so.10 (the 1.8 series of HDF5): # readelf -d /usr/lib64/libnetcdf.so.11 Dynamic section at offset 0x186b30 contains 31 entries: Tag Type Name/Value 0x0000000000000001 (NEEDED) Shared library: [libmfhdf.so.4.2.11] 0x0000000000000001 (NEEDED) Shared library: [libhdf5_hl.so.10] 0x0000000000000001 (NEEDED) Shared library: [libhdf5.so.10] 0x0000000000000001 (NEEDED) Shared library: [libm.so.6] 0x0000000000000001 (NEEDED) Shared library: [libcurl.so.4] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] 0x000000000000000e (SONAME) Library soname: [libnetcdf.so.11] [irrelevant entries stripped] This leads to the dreaded HDF5 version mismatch error: (obviously for the following command you'd need an input file, but any netCDF file will do, I believe) # cdo invertlat gmt10.nc tmp.nc Warning! ***HDF5 library version mismatched error*** The HDF5 header files used to compile this application do not match the version used by the HDF5 library to which this application is linked. Data corruption or segmentation faults may occur if the application continues. This can happen when an application was compiled by one version of HDF5 but linked with a different version of static or shared HDF5 library. You should recompile the application or check your shared library related settings such as 'LD_LIBRARY_PATH'. You can, at your own risk, disable this warning by setting the environment variable 'HDF5_DISABLE_VERSION_CHECK' to a value of '1'. Setting it to 2 or higher will suppress the warning messages totally. Headers are 1.8.17, library is 1.10.0 SUMMARY OF THE HDF5 CONFIGURATION ================================= General Information: ------------------- HDF5 Version: 1.10.0-patch1 Host system: x86_64-suse-linux-gnu Byte sex: little-endian Installation point: /usr [rest of the output stripped] Also, when looking at symbol resolution, lots of dubious resolutions are happening between the HDF5 libraries (.so.10 and .so.100): # LD_DEBUG=bindings cdo invertlat gmt10.nc tmp.nc [lots and lots of output stripped] 25643: binding file /usr/lib64/libhdf5.so.10 [0] to /usr/lib64/libhdf5.so.10 [0]: normal symbol `H5D__chunk_init' [...] 25643: binding file /usr/lib64/libhdf5.so.10 [0] to /usr/lib64/libhdf5.so.100 [0]: normal symbol `H5P_LST_FILE_ACCESS_ID_g' 25643: binding file /usr/lib64/libhdf5.so.10 [0] to /usr/lib64/libhdf5.so.10 [0]: normal symbol `H5P_facc_close' 25643: binding file /usr/lib64/libhdf5.so.10 [0] to /usr/lib64/libhdf5.so.100 [0]: normal symbol `H5P_CLS_GROUP_CREATE_g' [...] 25643: binding file /usr/lib64/libhdf5.so.10 [0] to /usr/lib64/libhdf5.so.100 [0]: normal symbol `H5T_NATIVE_UINT_FAST16_ALIGN_g' 25643: binding file /usr/lib64/libhdf5.so.10 [0] to /usr/lib64/libhdf5.so.100 [0]: normal symbol `H5E_SYSTEM_g' 25643: binding file /usr/lib64/libhdf5.so.10 [0] to /usr/lib64/libhdf5.so.100 [0]: normal symbol `H5T__conv_llong_schar' 25643: binding file /usr/lib64/libhdf5.so.10 [0] to /usr/lib64/libhdf5.so.100 [0]: normal symbol `H5HF_sect_single_free' 25643: binding file /usr/lib64/libhdf5.so.10 [0] to /usr/lib64/libhdf5.so.100 [0]: normal symbol `H5MF_sect_simple_can_shrink' [...] 25643: binding file /usr/lib64/libhdf5.so.100 [0] to /usr/lib64/libhdf5.so.100 [0]: normal symbol `H5A_close' 25643: binding file /usr/lib64/libhdf5.so.100 [0] to /usr/lib64/libhdf5.so.100 [0]: normal symbol `H5B2_TEST' 25643: binding file /usr/lib64/libhdf5.so.100 [0] to /usr/lib64/libhdf5.so.100 [0]: normal symbol `H5HF_HUGE_BT2_INDIR' 25643: binding file /usr/lib64/libhdf5.so.100 [0] to /usr/lib64/libhdf5.so.100 [0]: normal symbol `H5HF_HUGE_BT2_INDIR' Best regards Edward -- You are receiving this mail because: You are on the CC list for the bug.