opencv: move qcom-fastcv-binaries RDEPENDS to opencv-apps for qcom aarch64 #1271
Conversation
quic-ptak
requested review from
lumag,
ndechesne,
ricardosalveti,
sbanerjee-quic and
vkraleti
as code owners
Previously, qcom-fastcv-binaries was added to opencv, which is empty and not installed in the image. The dependency is now applied to opencv-apps, ensuring required FastCV libraries are included in qcom aarch64 builds. Signed-off-by: Pulkit Singh Tak <[email protected]>
Test run workflowTest jobs for commit 2d2c840
|
quic-ptak
changed the title
| # Only on ARMv8 Qualcomm machines | ||
| PACKAGECONFIG:append:qcom:aarch64 = " fastcv" | ||
| RDEPENDS:${PN}:append:qcom:aarch64 = " qcom-fastcv-binaries" | ||
| RDEPENDS:${PN}-apps:append:qcom:aarch64 = " qcom-fastcv-binaries" |
There was a problem hiding this comment.
The apps don't RDEPEND on the fastcv. libopencv-fastcv412 does.
However, could you please explain, how does it work? Is OpenCV dlopen()ing the libfastcvopt? In such a case, which library name is used for dlopen? Or is it being linked against libfastcvopt? Is there a way to make it linked?
There was a problem hiding this comment.
OpenCV dynamic packages: libopencv-fastcv, libopencv-core and libopencv-imgproc have build time dependency on libfastcv.a (provided by OpenCV and not from qcom-fastcv-binaries) which is statically linked. The lib: libfastcv.a does dlopen of libfastcvopt.so provided by qcom-fastcv-binaries package at runtime.
There was a problem hiding this comment.
Then please make those packages depend on libfastcvopt.
There was a problem hiding this comment.
And can upstream libfastcv.a be changed to use proper linking instead of dlopen?
There was a problem hiding this comment.
I think that's the point: one can OpenCV without FastCV and then sideload FastCV binaries.
There was a problem hiding this comment.
OpenCV when uses FastCV functionality on CPU doesn't need libfastcvopt.so. For that it uses libfastcv.a which is provided by upstream OpenCV. But when OpenCV calls FastCV DSP functionality, the same libfastcv.a does dlopen of libfastcvopt.so which serves as entry point of the pipeline. libfastcvopt.so needs libfastcvdsp_stub.so during runtime to offload the call to DSP subsystem. That's why for the sake of OpenCV calling FastCV DSP functionality all 3 kinds of libs (libfastcvopt.so, libfastcvdsp_stub.so and DSP skel libs) are needed for the smooth working. Hope this clears why we are trying to install qcom-fastcv-binaries packages through runtime dependency.
There was a problem hiding this comment.
Then please make those packages depend on libfastcvopt.
When we attempted to make qcom-fastcv-binaries a runtime dependency of the libopencv-core package, the build failed with the following QA error:
ERROR: opencv-4.12.0-r0 do_package_qa: QA Issue: libopencv-core rdepends on qcom-fastcv-binaries, but it isn't a build dependency, missing one of qcom-fastcv-binaries in DEPENDS or PACKAGECONFIG? [build-deps]
ERROR: opencv-4.12.0-r0 do_package_qa: Fatal QA errors were found, failing task.
This occurs because Yocto enforces that any runtime dependency must also be available during the build process to ensure reproducibility and proper QA checks. The issue was resolved by adding qcom-fastcv-binaries as a compile-time dependency (DEPENDS) instead of only a runtime dependency (RDEPENDS). Can this approach be applied in this context?
Test run workflowTest jobs for commit 9d31a57
|
Test Results 13 files ±0 25 suites ±0 41m 33s ⏱️ +3s For more details on these failures, see this check. Results for commit 9d31a57. ± Comparison against base commit 066eb02. |
3 participants
Previously, qcom-fastcv-binaries was added to opencv, which is empty and not installed in the image. The dependency is now applied to opencv-apps, ensuring required FastCV DSP libraries are included in qcom aarch64 builds.