ZED Stereo Camera Samples Won't Build Due to libGL.so

I recently downloaded the ZED SDK, and API from Github. No issues here. I am able to compile/run the ZED tools (prebuilt applications), but when I try to run sample programs (more on the range of scripts than full-fledged applications), I was told that I needed openCV and openGL. Again, no problem (although it did take my TX2 ~5 hours to install openCV, when I read that really 1.5 hours is normal, so that was a red flag to me). Now every time that I try to run a ZED sample, I get the error

make[2]: *** No rule to make target '/usr/lib/aarch64-linux-gnu/libGL.so', needed by 'ZED_Object_Detection'.  Stop.

I went to the listed directory, and discovered that there is a “libGL.so” file there, but the symbolic link is pointing to /usr/lib/aarch64-linux-gnu/tegra.libGL.so and this file does not exist. I am not very familiar with openGL, openCV, or in all honesty what .so files really are, and so I am slightly out of my depth here. After many hours of googling, I have found that apparently this is an incredibly common issue, and so hopefully not difficult to fix.

My specs:
Ubuntu 18.04.03
Jetpack 4.3
openGL 4.6
openCV 3.4.1

Please let me know if there’s any info that I can share to provide assistance in fixing this issue.

Although I won’t be able to answer you’ll probably need to provide which release is currently installed:

head -n 1 /etc/nv_tegra_release

Also, verify the basic install is correct with:

sha1sum -c /etc/nv_tegra_release

And post the output of:

ls -l /usr/lib/aarch64-linux-gnu/libGL.*

The output of the latter should look something like:

... libGL.so -> libGL.so.1.0.0
... libGL.so.1 -> libGL.so.1.0.0
... libGL.so.1.0.0

Also, what is the output of:

ldconfig -p | egrep 'libGL<li>'

Thanks for the info! Below are the responses in order:

:~$ head -n 1 /etc/nv_tegra_release
# R32 (release), REVISION: 3.1, GCID: 18186506, BOARD: t186ref, EABI: aarch64, DATE: Tue Dec 10 07:03:07 UTC 2019
:~$ sha1sum -c /etc/nv_tegra_release
sha1sum: /etc/nv_tegra_release: no properly formatted SHA1 checksum lines found
:~$ ls -l /usr/lib/aarch64-linux-gnu/libGL.*
lrwxrwxrwx 1 root root     14 Mar  3 15:34 /usr/lib/aarch64-linux-gnu/libGL.so -> tegra/libGL.so
lrwxrwxrwx 1 root root     14 May 10  2019 /usr/lib/aarch64-linux-gnu/libGL.so.1 -> libGL.so.1.0.0
-rw-r--r-- 1 root root 972968 May 10  2019 /usr/lib/aarch64-linux-gnu/libGL.so.1.0.0
:~$ ldconfig -p | egrep 'libGL<li>'
	libGL.so.1 (libc6,AArch64) => /usr/lib/aarch64-linux-gnu/libGL.so.1

Please let me know if there’s anything else that I can clarify!

This is something new related to going to packages instead of loose files for some content, and can be ignored for R32.3.1:

:~$ sha1sum -c /etc/nv_tegra_release
sha1sum: /etc/nv_tegra_release: no properly formatted SHA1 checksum lines found

Your linker is finding “libGL.so.1”, and in turn this implies it is finding the file the symbolic link points at, “libGL.so.1.0.0”. However, there should also be a “libGL.so” pointing at “libGL.so.1”, and this is missing.

There is a discrepancy between your system and the sample rootfs for libGL.so (just as speculation, perhaps caused by a package update of some sort). My “libGL.so” points at “libGL.so.1.0.0” in the same directory. Yours instead points to:

/usr/lib/aarch64-linux-gnu/libGL.so -> tegra/libGL.so
# Which is equivalent to the full path:
<b>/usr/lib/aarch64-linux-gnu/tegra/libGL.so</b>

Do you have this file? I suspect not, and this would cause the failure:

/usr/lib/aarch64-linux-gnu/<b><u><i>tegra</i></u></b>/libGL.so

The linker will logically refuse to list a file which does not exist, and even if the symbolic link exists, the file is still missing if it doesn’t point at actual content. Now if the file does exist, then the linker should list the file in the “ldconfig -p” unless there is some other error, e.g., a file of the wrong architecture or without read permission.

Thank you for your reply!

I can confirm that there is no file

/usr/lib/aarch64-linux-gnu/tegra/libGL.so

I wasn’t sure if this was due to some form of improper install, or if running various scripts to install the packages could have been the problem. I’m also not even aware of what a .so file is, and so I’m not sure if this is something that I can recreate, or if this is something that is installed when the Jetson is flashed. Are you able to provide more details about this, or supply any more troubleshooting ideas?

The “.so” files are dynamic libraries (relocatable libraries of functions). “ldconfig” is the linker, and is the tool for automatically finding libraries when an application wants to use a system library (developers can manually link to a library with “dlopen()”, but most people use the linker). “libGL.so” in particular is support for OpenGL. I suppose it is possible that the “tegra/libGL.so” is some old baggage from something else, or caused by some unknown update issue.

While it would be nice to know why this is incorrect, we can test for a workaround. You already have the file the symbolic link should be pointing at, and we can simply put the correct symbolic link back in (whatever caused the issue in the first place could come back though):

cd /usr/lib/aarch64-linux-gnu
sudo rm libGL.so
sudo ln -sf libGL.so.1.0.0 libGL.so
sudo ldconfig
# Now verify libGL.so shows up pointing to libGL.so.1.0.0:
ldconfig -p | egrep 'libGL<li>'

After this it should compile, but to emphasize, I don’t know what caused the incorrect symbolic link in the first place. It is possible that various GUI apps would crash if the wrong libGL.so is used, and even the GUI as a whole could crash if something is incorrect in how the graphics libraries are linked. Serial console and ssh would still work if you do encounter such an error.