Scenario: - latest ports, updated from svn - hdf5 updated to 1.12.0 - trying to compile graphics/vigra Result: - Fails with /usr/bin/c++ -DHasEXR -DHasHDF5 -DHasJPEG -DHasPNG -DHasTIFF -DHasZLIB -Dvigraimpex_EXPORTS -I/usr/tmp/a/SRC/FreeBSD-ports/head/graphics/vigra/work/vigra-8acd73a/include -isystem /usr/local/include -isystem /usr/local/include/OpenEXR -std=c++11 -pthread -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -fPIC -DH5_BUILT_AS_DYNAMIC_LIB -std=gnu++11 -MD -MT src/impex/CMakeFiles/vigraimpex.dir/hdf5impex.cxx.o -MF src/impex/CMakeFiles/vigraimpex.dir/hdf5impex.cxx.o.d -o src/impex/CMakeFiles/vigraimpex.dir/hdf5impex.cxx.o -c /usr/tmp/a/SRC/FreeBSD-ports/head/graphics/vigra/work/vigra-8acd73a/src/impex/hdf5impex.cxx /usr/tmp/a/SRC/FreeBSD-ports/head/graphics/vigra/work/vigra-8acd73a/src/impex/hdf5impex.cxx:193:5: error: no matching function for call to 'H5Oget_info_by_name3' H5Oget_info_by_name(loc_id, name, &infobuf, H5P_DEFAULT); ^~~~~~~~~~~~~~~~~~~ /usr/local/include/H5version.h:772:31: note: expanded from macro 'H5Oget_info_by_name' #define H5Oget_info_by_name H5Oget_info_by_name3 ^~~~~~~~~~~~~~~~~~~~ /usr/local/include/H5Opublic.h:188:15: note: candidate function not viable: requires 5 arguments, but 4 were provided H5_DLL herr_t H5Oget_info_by_name3(hid_t loc_id, const char *name, H5O_info2_t *oinfo, ^ 1 error generated. Analysis: - It seems that the HDF5 source code is incorrect - In H5version.h, H5Oget_info_by_name is defined as H5Oget_info_by_name3 - But the function signatures are different: . H5Oget_info_by_name( hid_t loc_id, const char *object_name, H5O_info_t *object_info, hid_t lapl_id ); /* from https://support.hdfgroup.org/HDF5/doc/RM/RM_H5O.html#Object-GetInfoByName */ . H5Oget_info_by_name3(hid_t loc_id, const char *name, H5O_info2_t *oinfo, unsigned fields, hid_t lapl_id); /* from /usr/local/include/H5Opublic.h */ Patch (getting vigra to compile, I have no idea whether H5O_INFO_ALL is the correct value to use): --- ./src/H5version.h.ORIG 2020-02-29 00:52:15.000000000 +0100 +++ ./src/H5version.h 2020-03-29 18:55:46.915455000 +0200 @@ -769,7 +769,7 @@ #ifndef H5Oget_info_by_name_vers #define H5Oget_info_by_name_vers 3 #endif /* H5Oget_info_by_name_vers */ - #define H5Oget_info_by_name H5Oget_info_by_name3 + #define H5Oget_info_by_name(loc_id, name, oinfo, lapl_id) H5Oget_info_by_name3(loc_id, name, oinfo, H5O_INFO_ALL, lapl_id) #elif H5Oget_info_by_name_vers == 2 #define H5Oget_info_by_name H5Oget_info_by_name2 #elif H5Oget_info_by_name_vers == 1 ... but looking around in this file the same problem probably exists for a number of other functions which have a "fields" parameter -- Martin
I have the same problem and problem with compile graphics/blender: executing: /usr/ports/graphics/blender/work/.build/bin/blender --help ld-elf.so.1: Shared object "libhdf5.so.103" not found, required by "libAlembic.so.1.7" Traceback (most recent call last): File "blender.1.py", line 56, in <module> Thank you.
There are several changes since HDF5 1.12.0, even on API level, see [1], sectiom "API compatibility report for the hdf5 library between 1.10.6 and 1.12.0 versions on x86_64". [1] https://portal.hdfgroup.org/display/support/HDF5%201.12.0#compatibility1120
https://lists.freebsd.org/pipermail/svn-ports-all/2020-March/246828.html reports french/med broken which apparently needs the older version of hdf5 retained as separate port. IMO (as a non-user but ports committer) this is critical and needs to be fixed properly before we branch 2020Q2.
How about a repocopy to of hdf5 to hdf5-1.10 and updating the main port to 1.12?
what about waiting for 2020Q2 first, and requesting an exp-run before committing anything?
(In reply to Rene Ladan from comment #4) Insufficient, because you can't use soversions to tell the hdf5 libs apart (at least not between 1.8.x and 1.10.x), and need more changes to sort things out, also downstream (french/med, for one). See htf5-18 for a rough sketch of what else needs to be done, it renames libraries, directories etc. after the build. The ports that will need to move over to htf5-110 also need more adjustments in dependency lines, library names, to follow suit. Either we can get a htf5-110 port in place and move all ports that can't support 1.12 to it, or we go with Antoine's suggestion and sort things out after 2020Q2 has branched. Not trivial with 1½ days left. I looked at making a new hdf5-110 to pave the way for sunpoet@s 1.12 and gave up after I'd looked at htf5-18 and everything. I'd guess this needs more time to get it right. +1 for Antoine's suggestion in comment #5.
(In reply to Matthias Andree from comment #6) We have several hdf ports already: hdf - 4.x hdf5-18 - 1.8 hdf5 - 1.10 Easiest way is to create hdf5-110, "move all ports that can't support 1.12 to it" and update hdf5 to 1.12: hdf - 4.x hdf5-18 - 1.8 hdf5-110 - 1.10 hdf5 - 1.12
@VVD, the roadmap is clear, but time's ticking fast if everything is to be in place before 2020Q2 which will branch in some 30 hours, and I'm not acquainted enough with the HDF5 consumers, and their switching is not going to be trivial.
Yes, let's wait after 2020Q2 is branched.
Sorry for the breakage. I suggest 2 exp-runs. 1st exp-run is for hdf5 1.12. After that, change the broken ports to hdf5110 (repocopied, 1.10.6) and request 2nd exp-run. Hopefully everything works with 2nd exp-run. BTW, hdf5-18 is only used by cad/freecad and cad/freecad/Makefile says "To be removed when french/med will be built against science/hdf5". Maybe we could move both ports (freecad and med) to hdf5 1.10 and remove hdf5-18.
Good plan, but again: a repocopy *may not be sufficient*, there will be more modifications to hdf5-110 and to its users required so that hdf5-110 and hdf5 can coexist in the same system.
any news here? I ask as ports-secteam (is as CC into the list)
MARKED AS SPAM
Gentle Ping from Ports-Secteam....
science/hdf5 has been updated to 1.12.2 and all dependent ports are fixed. See bug 265152.