Error while loading shared libraries: libcgmanager.so.0:

Hello,

I am facing shared library error while running this application.

==>
$ ./ACE006_USB_I2C_Bridging
./ACE006_USB_I2C_Bridging: error while loading shared libraries: libcgmanager.so.0: cannot open shared object file: No such file or directory

Even i tried to install it , but i faced the same error
==>
$ sudo apt-get update
apt-get: error while loading shared libraries: libcgmanager.so.0: cannot open shared object file: No such file or directory
==>
$ sudo apt-get install libcgmanager
apt-get: error while loading shared libraries: libcgmanager.so.0: cannot open shared object file: No such file or directory

I know nothing about the specific library or software, but have some tips.

You can list which libraries are actually visible in the default system library search path via:
ldconfig -p

You could have this filter specifically for your library:
ldconfig -p | grep -i 'cgmanager'

If this is in this default library search path, then all is well. Perhaps it just needs a symbolic link to the “.so.0” extension. If it doesn’t show up, then the library might be on the system, but in a non-standard search path. In that case:
sudo find / -iname 'libcmanager.so*'

Hello @linuxdev Team

I tried to follow above command , but i did found “cgmanager” or “libcmanager.so*”

admin@vc01:~/Vinay/abc$ ldconfig -p | grep -i 'cgmanager’
admin@vc01:~/Vinay/abc$
admin@vc01:~/Vinay/abc$ sudo find / -iname 'libcmanager.so*
[sudo] password for admin:
find: ‘/run/user/1002/gvfs’: Permission denied

Even i tried above by super user as well

admin@vc01:~/Vinay/abc**$ sudo su**
root@vc01:/home/admin/Vinay/abc# sudo find / -iname 'libcmanager.so*
find: ‘/run/user/1002/gvfs’: Permission denied

The lack of seeing the “cgmanager” in ldconfig -p implies the library is missing from the linker’s default search path, or that there was an error and the linker was unable to load it.

For the “find” command it is normal to not be able to read a gvfs directory, but the lack of finding “libcmanager.so*” (make sure the “*” is inside of the single quotes) implies the file itself is entirely missing and never made it so far as copy to the filesystem. Are you sure you installed this somewhere?

Hello

Hello

$ sudo apt-get update
apt-get: error while loading shared libraries: libcgmanager.so.0: cannot open shared object file: No such file or directory
==>I tried installing it but …
$ sudo apt-get install libcgmanager
apt-get: error while loading shared libraries: libcgmanager.so.0: cannot open shared object file: No such file or directory

==>
admin@vm97:~/Vinay/VKSINGH_GIT/jc96/BSP/Linux_for_Tegra/tools$ sudo find / -iname ‘libcmanager.so*’
[sudo] password for admin:
find: ‘/run/user/1002/gvfs’: Permission denied

Which L4T release are you using? See “head -n 1 /etc/nv_tegra_release”. The reason I ask is that I performed a locate on my host PC for libcgmanager, and I have a hit starting at L4T R19.3 and newer (where I flashed those versions and kept content for reference), up to and including the R28.x series. In the R32.x series and newer the package disappears and seems to no longer be used. I’m not sure of the relevance, but are you using an older package? Have you ever mixed older and newer L4T releases?

Hello,

$ head -n 1 /etc/nv_tegra_release
head: cannot open ‘/etc/nv_tegra_release’ for reading: No such file or directory

I am using L4T 32.4.4 , and never mixed older and newer versions.

There was one release when switching from NVIDIA content just being tar archives to actual .deb packages, but I’m thinking it was prior to R32.4.4. Right now I’m looking at an NX with R32.4.3, and this has nv_tegra_release, so I’m positive that missing this file on your R32.4.4 is definitely wrong.

Do note that during a flash JetPack/SDKM is just a front end to the flash software. The actual flash software is also somewhat independent of the flashed content. This needs a bit of explanation to show why this matters.

During setup on the host PC prior to flash the “driver package” produces the “~/nvidia/nvidia_sdk/JetPack...version.../Linux_for_Tegra” directory and content, except for “Linux_for_Tegra/rootfs/”. It is this latter which ends up being flashed to the Jetson. The content is first created with a purely Ubuntu filesystem unpacked there, and then the “apply_binaries.sh” script is run (with sudo) to overlay NVIDIA content into what would otherwise be purely Ubuntu. At this point you can call it “Linux for Tegra” (“L4T”).

Finally, as flash begins, some content of “rootfs/boot/” is added based on the parameters passed to the flash program, e.g., a device tree might be picked and added to the “rootfs/boot/” before generating the actual image to flash.

Although not relevant to this, there are many other partitions related to boot (non-Linux stages) which are stored on either eMMC (if it is an eMMC model) or QSPI memory (if SD card model and if a recent release…amount on QSPI differs depending on release). All of this content is part of the “driver package” and is not found within the rootfs image which is generated from “Linux_for_Tegra/rootfs/”. I say “not relevant” because we’re looking at content on the rootfs itself.

Mostly I am very curious as to why nv_tegra_release is missing on your particular release. libcgmanager.so should probably have never been part of the rootfs unless you’re manually adding it. On the other hand I see “apt” is failing to open because “apt” itself wants this. This shouldn’t be possible on this particular release.

The command “ldd” can list what libraries an application needs to dynamically link against in order to function. On my R32.4.3 NX (SD card model) I see this:

root@nx:~# ldd /usr/bin/apt-get 
        linux-vdso.so.1 (0x0000007fab87e000)
        libapt-private.so.0.0 => /usr/lib/aarch64-linux-gnu/libapt-private.so.0.0 (0x0000007fab7a9000)
        libapt-pkg.so.5.0 => /usr/lib/aarch64-linux-gnu/libapt-pkg.so.5.0 (0x0000007fab5ed000)
        libstdc++.so.6 => /usr/lib/aarch64-linux-gnu/libstdc++.so.6 (0x0000007fab459000)
        libgcc_s.so.1 => /lib/aarch64-linux-gnu/libgcc_s.so.1 (0x0000007fab435000)
        libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000007fab2db000)
        /lib/ld-linux-aarch64.so.1 (0x0000007fab853000)
        libresolv.so.2 => /lib/aarch64-linux-gnu/libresolv.so.2 (0x0000007fab2b6000)
        libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0 (0x0000007fab28a000)
        libz.so.1 => /lib/aarch64-linux-gnu/libz.so.1 (0x0000007fab25d000)
        libbz2.so.1.0 => /lib/aarch64-linux-gnu/libbz2.so.1.0 (0x0000007fab23d000)
        liblzma.so.5 => /lib/aarch64-linux-gnu/liblzma.so.5 (0x0000007fab20d000)
        liblz4.so.1 => /usr/lib/aarch64-linux-gnu/liblz4.so.1 (0x0000007fab1e1000)
        libzstd.so.1 => /usr/lib/aarch64-linux-gnu/libzstd.so.1 (0x0000007fab16b000)
        libudev.so.1 => /lib/aarch64-linux-gnu/libudev.so.1 (0x0000007fab141000)
        libsystemd.so.0 => /lib/aarch64-linux-gnu/libsystemd.so.0 (0x0000007fab0bc000)
        libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6 (0x0000007fab003000)
        libdl.so.2 => /lib/aarch64-linux-gnu/libdl.so.2 (0x0000007faafee000)
        librt.so.1 => /lib/aarch64-linux-gnu/librt.so.1 (0x0000007faafd7000)
        libgcrypt.so.20 => /lib/aarch64-linux-gnu/libgcrypt.so.20 (0x0000007faaf1c000)
        libgpg-error.so.0 => /lib/aarch64-linux-gnu/libgpg-error.so.0 (0x0000007faaefa000)

Nowhere in this list does it show that “apt-get” should ever care about “libcgmanager” (of any version). So I think something is “wonky” (one of those technical terms I wish I had a patent on) with your installed system.

If you run the command “sudo ldd /usr/bin/apt-get 2>&1 | tee log_ldd.txt”, then you should see what is linked against your apt-get, and it will produce the log file “log_ldd.txt” which you can attach to the forum.

There is one other twist in the story if your ldd does not show apt-get requiring the libcgmanager: One library can require yet another library in a chain of dependencies, and the ldd will only show what apt-get directly links against. Unfortunately I don’t think there is any sort of recursive version of ldd, but if your apt-get shows it requires libcgmanager, then this would be an error for your release. Somewhere along the line I’m wondering if some sort of apt command has broken dependencies. If not, then perhaps the original flashed image was at fault, e.g., with some sort of version mixing or from a failure of JetPack to correctly apply_binaries.sh.

Is your NX the SD card model dev kit? Or is it the eMMC model on a third party carrier board? Do you have valuable content you need to save if you were to flash again from scratch? In the end I’m thinking you will need to flash from scratch.