opencv4 @4.6.0 +contrib+eigen+java+nonfree+opencl+openmp+qt5+tbb+vtk: build failure related to tbb

[Gandoon (Erik Hedlund)]

I have had an issue building opencv4 @4.6.0_10 (upgrading from @4.6.0_3). The options I have used for a while are as follows +contrib+eigen+java+nonfree+opencl+openmp+qt5+tbb+vtk which worked fine until the previously mentioned version (rev 3). Now it failed to build. A workaround if you have the same problem that may or may not work for you is presented later.

A few changes seems to have broken the old opencv4 @4.6.0_3. A port rev-upgrade shows that two files has disappeared:

# port -v rev-upgrade
--->  Scanning binaries for linking errors
Could not open /opt/local/lib/libtbb.dylib: Error opening or reading file (referenced from /opt/local/lib/opencv4/libopencv_core.4.6.0.dylib)
Could not open /opt/local/lib/libprotobuf.30.dylib: Error opening or reading file (referenced from /opt/local/lib/opencv4/libopencv_dnn.4.6.0.dylib)
--->  Found 4 broken files, matching files to ports
--->  Found 1 broken port, determining rebuild order
You can always run 'port rev-upgrade' again to fix errors.
The following ports will be rebuilt: opencv4 @4.6.0+contrib+eigen+java+nonfree+opencl+openmp+qt5+tbb+vtk
Continue? [Y/n]:

The first of which seems to be related to an earlier upgrade of tbb and the move to onetbb which seems to have moved /opt/local/lib/libtbb.dylib to /opt/local/libexec/tbb/lib/libtbb.dylib and /opt/local/libexec/onetbb/lib/libtbb.dylib respectively. This allows the issue to be reasonably easily manually fixed (but it is not really a permanent fix) by soft-linking to the new location. I personally tried with linking the new onetbb version (# ln -s -v /opt/local/libexec/onetbb/lib/libtbb.dylib /opt/local/lib/libtbb.dylib) and that solved the first error (the new onetbb seems to work fine despite the dependency being on the old tbb). This will of course need to be tested if it works in reality as well, but for now it solved the port issue.

The second error seems to be related to opencv4 referencing the versioned libprotobuf.30.dylib. That one is now at libprotobuf.32.dylib so obviously the one it tries to find is no longer there.

However, with the jerry-rigging method mentioned above for the tbb reference there, opencv4 finally built and subsequently the second issue was also cleared.

So, something somewhere needs to be fixed for this to work smoothly.

[Gandoon (Erik Hedlund)]

Log of the build failing, before the manual fix

[mascguy (Christopher Nielsen)]

It looks like one component of the project opportunistically uses TBB, without respecting the path we pass to cmake.

I'll check to see if there's an upstream patch to fix. If not, I'll tackle it.

[Gandoon (Erik Hedlund)]

Replying to mascguy:

It looks like one component of the project opportunistically uses TBB, without respecting the path we pass to cmake.

I'll check to see if there's an upstream patch to fix. If not, I'll tackle it.

That sounds good.

Fortunately, I managed to find a workaround (as I usually do when I get fed up with a port not building). So hopefully if someone else has similar problems, they can use my experience as an interim solution until a proper fix is in place.

[mascguy (Christopher Nielsen)]

Erik, let me know if this is still an issue, with the latest release of opencv4 (4.8.0).

[Gandoon (Erik Hedlund)]

Replying to mascguy:

Erik, let me know if this is still an issue, with the latest release of opencv4 (4.8.0).

It is not. I just built it and no problems. I think we can close this ticket now.

Thanks :)

[mascguy (Christopher Nielsen)]

Replying to Gandoon:

I just built it and no problems. I did of course solve this with an interim solution before, but for me it builds, so unless someone else still has problems with tbb, I think we can close this ticket now.

Great, thanks for confirming!