opencv3/opencv4: opportunistic lib usage: tesseract, ogre, etc

[mascguy (Christopher Nielsen)]

Not a high priority, but it looks like we need to further audit this port, to avoid opportunistic linking.

With the caveat that we shouldn't preclude use of additional components, like tesseract: For libraries that are available across-the-board (in terms of macOS releases), consider adding them to the default list of dependencies.

Alternatively, consider additional variants, to explicitly enable those components.

[Christopher Nielsen <mascguy@…>]

In d7a27c537c8d0e89e36aa24ccb0e5e0d015dd551/macports-ports (master):

opencv4*: contrib: prevent opporunistic use of tesseract

• Also regen stale protobuf files, if necessary
• Cleanup

See: #63786

[Christopher Nielsen <mascguy@…>]

In f7b488117878b73df8a3cc40ff33c4416f5f6755/macports-ports (master):

opencv4*: contrib: prevent opportunistic use of ogre
Fixes: #63786

[cooljeanius (Eric Gallager)]

This also affects opencv3, too, btw.

[mascguy (Christopher Nielsen)]

Replying to cooljeanius:

This also affects opencv3, too, btw. Anyways, I'm testing building with trace mode and max variants enabled (except for vtk since that's broken for me currently) and intend to report back what trace mode says gets accessed afterwards...

Yep, next step is to clean up opencv3 as well.

There might still be a straggler or two left for opencv4 too, such as hdf5. But getting there!

[cooljeanius (Eric Gallager)]

main.log for opencv4

[cooljeanius (Eric Gallager)]

Replying to cooljeanius:

Anyways, I'm testing building with trace mode and max variants enabled (except for vtk since that's broken for me currently) and intend to report back what trace mode says gets accessed afterwards...

OK so this build failed for me; I just attached the entire log from it since that was easier than finding what the actual error was...

[mascguy (Christopher Nielsen)]

Replying to cooljeanius:

Replying to cooljeanius:

Anyways, I'm testing building with trace mode and max variants enabled (except for vtk since that's broken for me currently) and intend to report back what trace mode says gets accessed afterwards...

OK so this build failed for me; I just attached the entire log from it since that was easier than finding what the actual error was...

I've tested with virtually all variants enabled, from 10.8 thru Monterey, and all looks good.

With one caveat: +openni fails for Monterey, and might have issues on Big Sur as well. Can you try without that variant?

[mascguy (Christopher Nielsen)]

Replying to mascguy:

I've tested with virtually all variants enabled, from 10.8 thru Monterey, and all looks good.

With one caveat: +openni fails for Monterey, and might have issues on Big Sur as well. Can you try without that variant?

Just tested with trace mode enabled for 10.15, Big Sur, and Monterey, with variants: +contrib+eigen+gdal+java+nonfree+opencl+qt5+tbb. And only Monterey failed, with a similar failure to yours (for module gapi).

Looks like a linking issue. But there isn't a clear error regarding missing symbols and such, so need to dig into it further. (And appears to only occur with trace mode enabled.)

Can you also remove variants +debug and +tests - in addition to removing +openni - to pare things down a bit?

[Christopher Nielsen <mascguy@…>]

In 12d32da89a6d275f9de6dd4e4e4f3dc6c0aea369/macports-ports (master):

opencv4-devel: contrib: add lib dep hdf5
See: #63786

[cooljeanius (Eric Gallager)]

Replying to mascguy:

Replying to mascguy:

I've tested with virtually all variants enabled, from 10.8 thru Monterey, and all looks good.

With one caveat: +openni fails for Monterey, and might have issues on Big Sur as well. Can you try without that variant?

Just tested with trace mode enabled for 10.15, Big Sur, and Monterey, with variants: +contrib+eigen+gdal+java+nonfree+opencl+qt5+tbb. And only Monterey failed, with a similar failure to yours (for module gapi).

Looks like a linking issue. But there isn't a clear error regarding missing symbols and such, so need to dig into it further. (And appears to only occur with trace mode enabled.)

Can you also remove variants +debug and +tests - in addition to removing +openni - to pare things down a bit?

I'm trying removing them one at a time; with +debug removed it still fails with the same error; I'll try +tests next... actually, looking at the error a bit more closely, it says that /opt/local/lib/libopenblas.dylib is missing, but the file does actually exist, and it's listed as one of the files that trace mode hid... port provides /opt/local/lib/libopenblas.dylib says /opt/local/lib/libopenblas.dylib is provided by: OpenBLAS so maybe a dependency is just needed for OpenBLAS?

[Christopher Nielsen <mascguy@…>]

In 8d5533b0130aff88bc3bf0dfc6adaf0286cbc9b0/macports-ports (master):

opencv4: update to 4.6.0; add libquirc

• Also add lib dep hdf5, for contrib

See: ​https://github.com/macports/macports-ports/pull/15993
See: #63786

[cooljeanius (Eric Gallager)]

Replying to cooljeanius:

Replying to mascguy:

Replying to mascguy:

I've tested with virtually all variants enabled, from 10.8 thru Monterey, and all looks good.

With one caveat: +openni fails for Monterey, and might have issues on Big Sur as well. Can you try without that variant?

Just tested with trace mode enabled for 10.15, Big Sur, and Monterey, with variants: +contrib+eigen+gdal+java+nonfree+opencl+qt5+tbb. And only Monterey failed, with a similar failure to yours (for module gapi).

Looks like a linking issue. But there isn't a clear error regarding missing symbols and such, so need to dig into it further. (And appears to only occur with trace mode enabled.)

Can you also remove variants +debug and +tests - in addition to removing +openni - to pare things down a bit?

I'm trying removing them one at a time; with +debug removed it still fails with the same error; I'll try +tests next...

Update: removing +tests and +openni doesn't help; the build still fails with the same error even with those removed.

Edit: removing +contrib works, though, so I guess it's the +contrib variant that needs the OpenBLAS dependency for trace mode...

[mascguy (Christopher Nielsen)]

Replying to cooljeanius:

Edit: removing +contrib works, though, so I guess it's the +contrib variant that needs the OpenBLAS dependency for trace mode...

Yep, I still need to dig through the various CMake files, to see where it's being pulled in. Thanks for confirming!