no libv4l2 providers found

[ElD4n1]

Hi, I'm trying to create a layer for the ZED SDK, which depends on CUDA and V4L2. I almost resolved all depenency issues, but I am struggling to include V4L2 correctly such that the build succeeds.

Update: All repositories are checked out with the "honister" branch.

bblayers.conf:

POKY_BBLAYERS_CONF_VERSION = "2"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
  /home/${USER}/Projects/B-tastic.Device.Firmware/poky/meta \
  /home/${USER}/Projects/B-tastic.Device.Firmware/poky/meta-poky \
  /home/${USER}/Projects/B-tastic.Device.Firmware/poky/meta-yocto-bsp \
  /home/${USER}/Projects/B-tastic.Device.Firmware/meta-tegra \
  /home/${USER}/Projects/B-tastic.Device.Firmware/meta-tegra/contrib \
  /home/${USER}/Projects/B-tastic.Device.Firmware/sources/meta-zed \
  /home/${USER}/Projects/B-tastic.Device.Firmware/sources/meta-btastic-device \
  "

local.conf:

CONF_VERSION = "2"

MACHINE ?= "jetson-nano-2gb-devkit"

IMAGE_CLASSES += "image_types_tegra"
IMAGE_FSTYPES = "tegraflash"

SSTATE_DIR ?= "/home/${USER}/Yocto/sstate_dir"
DL_DIR ?= "/home/${USER}/Yocto/downloads"

GCCVERSION = "8.%"

Here is my recipe (zed-sdk_3.6.1.bb):

LICENSE = "CLOSED"
LIC_FILES_CHKSUM = ""

SRC_URI = "https://stereolabs.sfo2.cdn.digitaloceanspaces.com/zedsdk/3.6/ZED_SDK_Tegra_JP46_v${PV}.run"
SRC_URI[sha256sum] = "7f555730aab713270c612264fbe41716c2faca2fdf5b4290c8db3f0e5e957e71"

DEPENDS = "cross-localedef-native qemuwrapper-cross libv4l v4l-utils"
RDEPENDS:${PN} += "cuda-cudart cuda-driver libjpeg-turbo8 libturbojpeg libusb1 openblas libarchive curl zlib libpng tegra-libraries tegra-libraries-libv4l-plugins libv4l"

# we should skip this check for binary recipes
INSANE_SKIP:${PN} += "ldflags"
# when I skip this here, then the build of the image fails with a similar error
#INSANE_SKIP:${PN} += "file-rdeps"

do_unpack () {
	chmod 777 ${DL_DIR}/ZED_SDK_Tegra_JP46_v${PV}.run
	${DL_DIR}/ZED_SDK_Tegra_JP46_v${PV}.run --noexec --target ${S}
}

do_patch[noexec] = "1"
do_configure[noexec] = "1"
do_compile[noexec] = "1"

do_install () {
	installation_folder="${D}/usr/local/zed"
	install -D "${S}/lib/libsl_zed.so" -t "${installation_folder}/lib"
	install -D "${S}/include/sl"/* -t "${installation_folder}/include/sl"
	install "${S}/zed-config"* "${installation_folder}/"
	install -d "${installation_folder}/settings"
	install -D "${S}/99-slabs.rules" -t "${D}/etc/udev/rules.d" -m 777
	install -D "${S}/zed.conf" -t "${D}/etc/ld.so.conf.d"
}

FILES:${PN} += "/usr/local/zed"

Now when i build the recipe using bitbake zed-sdk, the build fails with:

Loading cache: 100% |######################################################################################################################################################################################################################################| Time: 0:00:00
Loaded 1695 entries from dependency cache.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION           = "1.52.0"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "universal"
TARGET_SYS           = "aarch64-poky-linux"
MACHINE              = "jetson-nano-2gb-devkit"
DISTRO               = "poky"
DISTRO_VERSION       = "3.4"
TUNE_FEATURES        = "aarch64 armv8a crc"
TARGET_FPU           = ""
meta                 
meta-poky            
meta-yocto-bsp       = "HEAD:0b500dba7ad1eb222b1703795967da7f88aeeb50"
meta-tegra           
contrib              = "HEAD:5fd61c425b16cf028a17245d7dfaa82c44d879c3"
meta-zed             
meta-btastic-device  = "master:60605306244d73db35b966113bd6bbf952e04f1b"

Initialising tasks: 100% |#################################################################################################################################################################################################################################| Time: 0:00:00
Sstate summary: Wanted 208 Local 205 Network 0 Missed 3 Current 189 (98% match, 99% complete)
Removing 2 stale sstate objects for arch armv8a: 100% |####################################################################################################################################################################################################| Time: 0:00:00
NOTE: Executing Tasks
ERROR: zed-sdk-3.6.1-r0 do_package_qa: QA Issue: /usr/local/zed/lib/libsl_zed.so contained in package zed-sdk requires libv4l2.so()(64bit), but no providers found in RDEPENDS:zed-sdk? [file-rdeps]
WARNING: zed-sdk-3.6.1-r0 do_package_qa: QA Issue: zed-sdk-dbg: found library in wrong location: /usr/local/zed/lib/.debug/libsl_zed.so
zed-sdk: found library in wrong location: /usr/local/zed/lib/libsl_zed.so [libdir]
ERROR: zed-sdk-3.6.1-r0 do_package_qa: QA run found fatal errors. Please consider fixing them.
ERROR: Logfile of failure stored in: /home/datastorage/Projects/B-tastic.Device.Firmware/build/tmp/work/armv8a-poky-linux/zed-sdk/3.6.1-r0/temp/log.do_package_qa.3344141
ERROR: Task (/home/datastorage/Projects/B-tastic.Device.Firmware/sources/meta-zed/recipes-core/zed-sdk/zed-sdk_3.6.1.bb:do_package_qa) failed with exit code '1'
NOTE: Tasks Summary: Attempted 1425 tasks of which 1422 didn't need to be rerun and 1 failed.

Summary: 1 task failed:
  /home/datastorage/Projects/B-tastic.Device.Firmware/sources/meta-zed/recipes-core/zed-sdk/zed-sdk_3.6.1.bb:do_package_qa
Summary: There was 1 WARNING message shown.
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.

But when I look the output of the libv4l2-minimal recipe, libv4l2.so is there:

$ ls /home/${USER}/Projects/B-tastic.Device.Firmware/build/tmp/work/armv8a_tegra-poky-linux/libv4l2-minimal/1.18.0-r0/sysroot-destdir/usr/lib
libv4l  libv4l1.so  libv4l1.so.0  libv4l1.so.0.0.0  libv4l2rds.so  libv4l2rds.so.0  libv4l2rds.so.0.0.0  libv4l2.so  libv4l2.so.0  libv4l2.so.0.0.0  libv4lconvert.so  libv4lconvert.so.0  libv4lconvert.so.0.0.0  pkgconfig  v4l1compat.so  v4l2convert.so

I am quite a Yotco beginner and at this point I can't make any sense of this error message. What am I missing?

[madisongh]

The error message is pointing to the bare .so, rather than the SONAME-named library, so you may need to add lib4l-dev to the runtime dependencies.

[ElD4n1]

Thanks for the reply!

Unfortunately adding lib4l2-dev to the runtime depencies didn't do the trick.

Based on your hint that the error message is about the bare .so, I tried replacing the symlink with a copy of the actual .so by creating the followinglibv4l2-minimal_1.18.0.bbappend:

do_install:append:tegra() {
    install ${D}${libdir}/libv4l2.so.0.0.0 ${D}${libdir}/libv4l2.so
}

The error stays the same, but an additional warning popped up though:

NOTE: Executing Tasks
WARNING: libv4l2-minimal-1.18.0-r0 do_package: libv4l-1.18.0 was registered as shlib provider for libv4l2.so.0, changing it to libv4l-dev-1.18.0 because it was built later
ERROR: zed-sdk-3.6.1-r0 do_package_qa: QA Issue: /usr/local/zed/lib/libsl_zed.so contained in package zed-sdk requires libv4l2.so()(64bit), but no providers found in RDEPENDS:zed-sdk? [file-rdeps]
WARNING: zed-sdk-3.6.1-r0 do_package_qa: QA Issue: zed-sdk-dbg: found library in wrong location: /usr/local/zed/lib/.debug/libsl_zed.so
zed-sdk: found library in wrong location: /usr/local/zed/lib/libsl_zed.so [libdir]
ERROR: zed-sdk-3.6.1-r0 do_package_qa: QA run found fatal errors. Please consider fixing them.
ERROR: Logfile of failure stored in: /home/datastorage/Projects/B-tastic.Device.Firmware/build/tmp/work/armv8a-poky-linux/zed-sdk/3.6.1-r0/temp/log.do_package_qa.1986296
ERROR: Task (/home/datastorage/Projects/B-tastic.Device.Firmware/sources/meta-zed/recipes-core/zed-sdk/zed-sdk_3.6.1.bb:do_package_qa) failed with exit code '1'
NOTE: Tasks Summary: Attempted 1425 tasks of which 1413 didn't need to be rerun and 1 failed.

Executing the file command verifies that it is a bare .so now:

$ file /home/datastorage/Projects/B-tastic.Device.Firmware/build/tmp/work/armv8a_tegra-poky-linux/libv4l2-minimal/1.18.0-r0/sysroot-destdir/usr/lib/libv4l2.so
/home/datastorage/Projects/B-tastic.Device.Firmware/build/tmp/work/armv8a_tegra-poky-linux/libv4l2-minimal/1.18.0-r0/sysroot-destdir/usr/lib/libv4l2.so: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, BuildID[sha1]=cd6317d2d2e024bafc75d595a93e845dce23eb2e, stripped

Can this be some kind of timing problem maybe?

[ElD4n1]

Ok I have a hack now that enables a successful build, but I doubt that this is a final solution for production (and I didn't even try to run it yet):

When I do an objdump on the libv4l2.so then the SONAME coming out is libv4l2.so.0, so i assumed ZED SDK expects this to be libv4l2.so instead. Now I manually copied libv4l2.so.0.0.0 (the bare .so) from libv4l2-minimal output artifacts to my own recipe, renamed it to libv4l2.so and patched SONAME using patchelf --set-soname libv4l2.so libv4l2.so. When I now include this besides the /usr/local/zed/lib/libsl_zed.so I get a new error ERROR: zed-sdk-3.6.1-r0 do_package: QA Issue: File '/usr/local/zed/lib/libv4l2.so' from zed-sdk was already stripped, this will prevent future debugging! [already-stripped], but at least this one can be skipped with INSANE_SKIP now and the image build succeeds as well.

Update: I now changed my approach to instead patching the needed version of libv4l2 of libsl_zed.so to the one provided by meta-tegra by including this line in the do_install() of my recipe: patchelf --replace-needed libv4l2.so libv4l2.so.0 "${installation_folder}/lib/libsl_zed.so"

Lets see if this works at runtime, anyway, thanks for the pointer!

[madisongh]

You might try installing the SDK on a Jetson running stock JetPack/L4T and see how the libv4l2.so linkage resolves itself... NVIDIA plays some games with that library and symlinks to redirect to the copy it provides in L4T. We might be able to adjust our recipes to better emulate that, to allow for dropping in binary blobs like this more easily.

[timongentzsch]

I was wondering if there is already a final solution to this problem? I have a similar issue when I want to start a svo recording in a docker container with the ZED SDK (using nvidias runtime). Strangely, all the other functionality (Depth sensing, Groundplane estimation, object detection etc.) of the SDK works without problems, only the recording in conjunction with libv4l doesn't seem to work.

First I got the error that the /usr/lib/aarch64-linux-gnu/libv4l/plugins-wrapped/libv4l2_nvvidconv.so could not be found. After I symlinked it manually from /usr/lib/aarch64-linux-gnu/libv4l/plugins/libv4l2_nvvidconv_wrapper.so (probably this recipe should be updated since nvidia places it somewhere else by default), the error disappears but the program segfaults immediatly.

I built the yocto image with following BASE_INSTALL: nvidia-docker cuda-toolkit cuda-driver cuda-target-environment tensorrt-core tensorrt-plugins-prebuilt python3-tensorrt v4l-utils libv4l Is there something Im missing out?

[madisongh]

@timongentzsch which meta-tegra branch are you using? I just ran some checks using dunfell (R32.6.1) and all of the libv4l stuff looks like it's getting mapped as it should.

[timongentzsch]

Thats weird, I'm on dunfell branch, too. Maybe I'm missing some installs. I'm using nvidia-docker cuda-toolkit cuda-driver cuda-target-environment tensorrt-core tensorrt-plugins-prebuilt python3-tensorrt v4l-utils libv4l.

[madisongh]

You should at least addtegra-libraries-multimedia-v4l, if it's not getting included already. You may need others, and if this zed thing doesn't explicitly document its exact dependencies, you may need to go on some hunting expeditions to find them. I was testing with the demo-image-full recipe in the demo distro, which includes a lot of packages - about as close to the stock JetPack kitchen-sink image as I have.

You will still need the extra symlink for the bare libv4l2.so, since by default we don't automatically map in content from the -dev packages, but the plugins under /usr/lib/aarch64-linux-gnu/libv4l should all be there.

[madisongh]

Also make sure you've updated your meta-tegra to latest on the dunfell branch - there was a fix specifically for tegra-libraries-multimedia-v4l container compatibility that went in about a week ago.

[timongentzsch]

Sry for the late reply. I can confirm that this problem has been resolved with the latest dunfell branch.