Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

opencv4[contrib] does not pick up hdf5 and tesseract for arm64-windows #27857

Closed
aungthetnaing opened this issue Nov 16, 2022 · 5 comments
Closed
Assignees
Labels
category:port-bug The issue is with a library, which is something the port should already support Stale

Comments

@aungthetnaing
Copy link
Contributor

.\vcpkg.exe install opencv4[contrib]
Computing installation plan...
The following packages will be built and installed:

  • bzip2[core,tool]:x86-windows -> 1.0.8#3
  • curl[core,non-http,schannel,ssl,sspi]:x86-windows -> 7.84.0#2
  • giflib[core]:x86-windows -> 5.2.1#3
  • hdf5[core,szip,zlib]:x86-windows -> 1.12.2#3
  • leptonica[core]:x86-windows -> 1.82.0
  • libarchive[bzip2,core,libxml2,lz4,lzma,openssl,zstd]:x86-windows -> 3.6.1#1
  • libiconv[core]:x86-windows -> 1.17
  • libjpeg-turbo[core]:x86-windows -> 2.1.4
  • liblzma[core]:x86-windows -> 5.2.5#6
  • libpng[core]:x86-windows -> 1.6.38
  • libwebp[core,libwebpmux,nearlossless,simd,unicode]:x86-windows -> 1.2.4
  • libxml2[core]:x86-windows -> 2.9.14#1
  • lz4[core]:x86-windows -> 1.9.3#4
    opencv4[contrib,core,default-features,dnn,jpeg,png,quirc,tiff,webp]:x86-windows -> 4.6.0#8
  • openjpeg[core]:x86-windows -> 2.5.0
  • openssl[core]:x86-windows -> 3.0.7#1
  • protobuf[core]:x86-windows -> 3.21.8
  • quirc[core]:x86-windows -> 1.1#3
  • szip[core]:x86-windows -> 2.1.1#9
  • tesseract[core]:x86-windows -> 5.2.0#3
  • tiff[core,jpeg,lzma,zip]:x86-windows -> 4.4.0#1
  • zlib[core]:x86-windows -> 1.2.13
  • zstd[core]:x86-windows -> 1.5.2#1

.\vcpkg.exe install opencv4[contrib]:arm64-windows
Computing installation plan...
The following packages will be built and installed:

  • libjpeg-turbo[core]:arm64-windows -> 2.1.4
  • liblzma[core]:arm64-windows -> 5.2.5#6
  • libpng[core]:arm64-windows -> 1.6.38
  • libwebp[core,libwebpmux,nearlossless,simd,unicode]:arm64-windows -> 1.2.4
    opencv4[contrib,core,default-features,dnn,jpeg,png,quirc,tiff,webp]:arm64-windows -> 4.6.0#8
  • protobuf[core]:arm64-windows -> 3.21.8
  • quirc[core]:arm64-windows -> 1.1#3
  • tiff[core,jpeg,lzma,zip]:arm64-windows -> 4.4.0#1
  • zlib[core]:arm64-windows -> 1.2.13

Eventually, arm64-windows install will fail with failure to locate HDF5 and Tesseract.

@aungthetnaing
Copy link
Contributor Author

"contrib": {
"description": "opencv_contrib module",
"dependencies": [
{
"name": "hdf5",
"platform": "!uwp & !(windows & (arm | arm64)) & !ios"
},
{
"name": "tesseract",
"platform": "!uwp & !(windows & (arm | arm64)) & !ios"
}
]
},

However, if I'm building natively in ARM64, the install looks for the dependencies. If building cross compilation from x64. install will pass but find_package will evenentually since generated OpenCVModules.cmake still has the followings:
find_dependency(HDF5)
find_dependency(Tesseract)

@dg0yt
Copy link
Contributor

dg0yt commented Nov 16, 2022

Useful observations.
IMO opencv4 features and dependencies need to be modeled differently, to simplify dependency usage and export. At least for hdf5, the situation is that we can hardly support any cross build (unless we know certain configuration parameters). It would be easy to model this for a feature via supports. (Features can be checked in the port file.) But what I see is dependencies with platform. (Dependencies cannot be checked easily in the port file.)

@aungthetnaing
Copy link
Contributor Author

For now, workaround is to change in vcpkg.json for opencv4

"contrib": {
"description": "opencv_contrib module",
"dependencies": [
{
"name": "hdf5",
"platform": "!uwp & !ios"
},
{
"name": "tesseract",
"platform": "!uwp & !ios"
}
]
},

In that way, native build will pass without issue.

@aungthetnaing
Copy link
Contributor Author

HDF5 cross-compile issue is #24898, once that's closed, my proposed fix can be applicable for both cases.

@LilyWangLL LilyWangLL added the category:port-bug The issue is with a library, which is something the port should already support label Nov 17, 2022
@github-actions
Copy link

github-actions bot commented Oct 7, 2023

This is an automated message. Per our repo policy, stale issues get closed if there has been no activity in the past 180 days. The issue will be automatically closed in 14 days. If you wish to keep this issue open, please add a new comment.

@github-actions github-actions bot added the Stale label Oct 7, 2023
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Oct 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
category:port-bug The issue is with a library, which is something the port should already support Stale
Projects
None yet
Development

No branches or pull requests

3 participants