Opened 3 years ago

Closed 11 months ago

Last modified 11 months ago

#62065 closed defect (fixed)

hdf5 / field3d / openimageio dylib mismatch on builders; causes blender builds to fail

Reported by: jasonliu-- (Jason Liu) Owned by: MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)
Priority: Normal Milestone:
Component: ports Version: 2.6.4
Keywords: Cc: ryandesign (Ryan Carsten Schmidt), kencu (Ken), eborisch (Eric A. Borisch), Dave-Allured (Dave Allured), cooljeanius (Eric Gallager), catap (Kirill A. Korinsky), mascguy (Christopher Nielsen)
Port: blender, openimageio, field3d, hdf5

Description

There appears to be a dylib version mismatch between a couple of the packages in the ports tree. As a result, all of the builds for blender are failing, with the following error:

dyld: Library not loaded: /opt/local/lib/libhdf5.103.dylib
  Referenced from: /opt/local/lib/libOpenImageIO.2.1.dylib
  Reason: image not found

OpenImageIO is dependent on hdf5, not directly, but by way of depending on field3d.

I encountered this same error on my own machine, and did some troubleshooting. It appears to have something to do with this PR, which updated the hdf5 port to version 1.12.0:

https://github.com/macports/macports-ports/pull/7983

To get the error to go away on my machine, I had to reactivate hdf5 @1.10.7. Running port contents on hdf5, it turns out that libhdf5.103.dylib exists in hdf5 @1.10.7, but doesn't exist in hdf5 @1.12.0. Instead, hdf5 @1.12.0 has libhdf5.200.dylib.

I'm not really sure how to fix this on the builders though, since PR7983 included a revbump of field3d to revision 11, which should have caused it to get rebuilt against hdf5 @1.12.0, if I'm not mistaken. I'm not familiar with field3d, so I don't know whether or not a rebuild would have caused field3d to pick up libhdf5.200.dylib.

Change History (18)

comment:1 Changed 3 years ago by eborisch (Eric A. Borisch)

OpenImageIO should advertise its dependence on hdf5 so that it can get caught in the (semi-manual) revbump cycle whenever hdf5 is updated.

comment:2 Changed 3 years ago by jasonliu-- (Jason Liu)

Originally I thought so too, but I grepped through the OpenImageIO source code, and its code never actually makes any calls to hdf5. It only ever calls field3d.

comment:3 Changed 3 years ago by jmroot (Joshua Root)

Then OpenImageIO is overlinked, and that should be fixed.

comment:4 Changed 3 years ago by jmroot (Joshua Root)

Owner: changed from admin@… to MarcusCalhoun-Lopez
Status: newassigned

comment:5 Changed 3 years ago by jmroot (Joshua Root)

Component: buildbot/mpbbports

comment:6 Changed 3 years ago by jasonliu-- (Jason Liu)

That's what I find odd. In one of the CMakeLists.txt files, there's clearly the following line:

src/field3d.imageio/CMakeLists.txt:

add_oiio_plugin (field3dinput.cpp field3doutput.cpp
                 INCLUDE_DIRS ${FIELD3D_INCLUDES}
                 LINK_LIBRARIES ${FIELD3D_LIBRARY}
                                ${HDF5_LIBRARIES}
                                ${SZIP_LIBRARY})

But in the rest of OpenImageIO's source code, there are no other references to "hdf". I suppose that line could technically qualify oiio as being dependent on hdf5, as Eric had said.

comment:7 Changed 3 years ago by jmroot (Joshua Root)

As things currently stand, openimageio needs its revision bumped whenever hdf5's library major version changes. From what you've said, it looks like that may not need to be the case though.

comment:8 Changed 3 years ago by Dave-Allured (Dave Allured)

I'm partly responsible for the HDF5 update in https://github.com/macports/macports-ports/pull/7983, so I should pitch in here. It appears that the dependency field3d is happy with the update to HDF5 1.12.0. Also I agree with Joshua's initial assessment, this is overlinking and nothing more. Adding a secondary dependency would be counterproductive.

Now I see that OpenImageIO has undergone some major changes in the past 6 months since since the MacPorts current version 2.1.7.0. OIIO is currently at 2.2.11.1. Some of those changes are in the CMake system. I am no CMake expert, but I can experiment with the most recent OIIO version.

Meanwhile, has anyone else tried any recent release of OpenImageIO? Is there some known reason to hold back to older OIIO versions?

comment:9 Changed 3 years ago by jasonliu-- (Jason Liu)

If OIIO has undergone major changes in the past 6 months, then it's quite possible that updating the OIIO port could break anything that's dependent on it. For example, the newest version of Blender (released on 2021-Jan-20) was written against OIIO 2.1.15.0. It's possible that Blender would still work if compiled against the latest OIIO, but I haven't had time to try it.

comment:10 Changed 3 years ago by Dave-Allured (Dave Allured)

Reported upstream: https://devtalk.blender.org/t/openimageio-update-to-2-2-11-1-or-latest/17410

The first responder calls this OIIO update a "minor release" compared to 2.1.5.0, therefore probably safe to update here. I don't know about the handful of other ports that are dependent on OIIO.

comment:11 Changed 3 years ago by jasonliu-- (Jason Liu)

I'm not so sure that when the person said "minor release", that they intended "minor" to mean the same thing as "insignificant". Going from 2.1.x to 2.2.x is indeed an increment to the "minor version number", if you go by the nomenclature of <major>.<minor>.<patch> for version numbering. However, reading through the release notes on OIIO's Github page, the things that were added or changed between OIIO the 2.1 and 2.2 branches is a pretty long list.

Since I am the person who wrote the portfiles for all of the ports that are dependent on OIIO, I would need to try building all of those ports against an updated OIIO portfile before I would be comfortable with having a new version of OIIO committed to the public ports tree.

Regardless, looking at the builders, it looks like the buildbots have "caught up" with having a working combination of hdf5 / field3d / openimageio, so the builds for Blender are currently working, for the time being.

I'm not saying that we shouldn't update OIIO to a newer version. It's just that I'm currently working on an update to the USD and Blender ports, so I'll need to circle back around to OIIO after I get those merged. If the newer versions of OIIO solve the overlinking problem with hdf5, then obviously that would be best. It is definitely an encouraging sign, though, if Arch's Blender package is currently being built against the newest OIIO 2.2 release.

Last edited 3 years ago by jasonliu-- (Jason Liu) (previous) (diff)

comment:12 Changed 3 years ago by Dave-Allured (Dave Allured)

Jason, I appreciate your efforts and level of care with the OIIO related ports. Please take your time, only update OIIO when you think it is appropriate. Thanks.

comment:13 Changed 3 years ago by Dave-Allured (Dave Allured)

Cc: Dave-Allured added

comment:14 Changed 20 months ago by cooljeanius (Eric Gallager)

Cc: cooljeanius added

comment:15 Changed 11 months ago by catap (Kirill A. Korinsky)

Resolution: fixed
Status: assignedclosed

In 4493efc8478e2bc705529a3b2d3b87a259e39107/macports-ports (master):

field3d: fix build before macOS 10.9

Closes: #62065

comment:16 Changed 11 months ago by jmroot (Joshua Root)

Cc: catap added

@catap: Is the OpenImageIO overlinking that is the real underlying bug here actually fixed?

comment:17 Changed 11 months ago by mascguy (Christopher Nielsen)

Cc: mascguy added

comment:18 in reply to:  16 Changed 11 months ago by catap (Kirill A. Korinsky)

Replying to jmroot:

@catap: Is the OpenImageIO overlinking that is the real underlying bug here actually fixed?

Seems so.

Note: See TracTickets for help on using tickets.