Bug 245168 - science/hdf5: update breaks downstream ports // [patch] incorrect function signature for H5Oget_info_by_name
Summary: science/hdf5: update breaks downstream ports // [patch] incorrect function si...
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Po-Chuan Hsieh
URL:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2020-03-29 17:07 UTC by Martin Birgmeier
Modified: 2022-07-18 12:57 UTC (History)
9 users (show)

See Also:
bugzilla: maintainer-feedback? (sunpoet)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Birgmeier 2020-03-29 17:07:55 UTC
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
Comment 1 lumiwa 2020-03-29 20:32:56 UTC
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.
Comment 2 Rainer Hurling freebsd_committer freebsd_triage 2020-03-30 06:03:38 UTC
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
Comment 3 Matthias Andree freebsd_committer freebsd_triage 2020-03-30 08:00:20 UTC
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.
Comment 4 Rene Ladan freebsd_committer freebsd_triage 2020-03-30 11:21:06 UTC
How about a repocopy to of hdf5 to hdf5-1.10 and updating the main port to 1.12?
Comment 5 Antoine Brodin freebsd_committer freebsd_triage 2020-03-30 11:46:42 UTC
what about waiting for 2020Q2 first,  and requesting an exp-run before committing anything?
Comment 6 Matthias Andree freebsd_committer freebsd_triage 2020-03-30 12:40:55 UTC
(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.
Comment 7 Vladimir Druzenko freebsd_committer freebsd_triage 2020-03-30 15:18:08 UTC
(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
Comment 8 Matthias Andree freebsd_committer freebsd_triage 2020-03-30 15:21:05 UTC
@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.
Comment 9 Rene Ladan freebsd_committer freebsd_triage 2020-03-30 17:24:20 UTC
Yes, let's wait after 2020Q2 is branched.
Comment 10 Po-Chuan Hsieh freebsd_committer freebsd_triage 2020-03-31 13:30:55 UTC
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.
Comment 11 Matthias Andree freebsd_committer freebsd_triage 2020-03-31 13:37:11 UTC
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.
Comment 12 Jochen Neumeister freebsd_committer freebsd_triage 2020-05-23 12:22:32 UTC
any news here? I ask as ports-secteam (is as CC into the list)
Comment 13 WillieLogue 2020-07-24 09:35:41 UTC
MARKED AS SPAM
Comment 14 Jochen Neumeister freebsd_committer freebsd_triage 2020-08-08 18:36:38 UTC
Gentle Ping from Ports-Secteam....
Comment 15 Po-Chuan Hsieh freebsd_committer freebsd_triage 2022-07-18 12:57:47 UTC
science/hdf5 has been updated to 1.12.2 and all dependent ports are fixed. See bug 265152.