For all issues regarding the Forums use, please, refer to the Forum Rules.
Need professional assistance?
Need to speed up your development?
Have a look at our:
Samples & Tools
Need some functionality extending standard OCCT capabilities?
Check out our:
This looks like some sort of NVIDIA driver related issue.
Any suggestions on how to rework the configure and get this fixed would be a big help
The most probably NVIDIA drivers have been installed incorrectly.
/usr/lib/libGL.so can not find some symbols.
Try to make :
> ldd -r /usr/lib/libGL.so
here's the output:
ldd -r /usr/lib/libGL.so
linux-gate.so.1 => (0xf7f9a000)
libGLcore.so.1 => /usr/lib/libGLcore.so.1 (0xf6f5d000)
libnvidia-tls.so.1 => /usr/lib/libnvidia-tls.so.1 (0xf6f5b000)
libm.so.6 => /lib/libm.so.6 (0xf6f33000)
libXext.so.6 => /usr/lib/libXext.so.6 (0xf6f23000)
libX11.so.6 => /usr/lib/libX11.so.6 (0xf6df3000)
libdl.so.2 => /lib/libdl.so.2 (0xf6dee000)
libc.so.6 => /lib/libc.so.6 (0xf6c7d000)
libXau.so.6 => /usr/lib/libXau.so.6 (0xf6c7a000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0xf6c5e000)
I still get the make error, I also note there is an earlier warning that is probably related:
*** Warning: linker path does not have real file for library -lXt.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libXt and none of the candidates passed a file format test
*** using a file magic. Last file checked: /lib/librt-2.10.1.so
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.
Thanks for your help, also the subsequent post with a script did not work as my system does not have a /usr/lib64/nvidia directory.
This sure sounds like an NVIDIA adventure so I've fixed my inittab for the eventual driver crash.
Are you running Fedora. In that case it might be that libGL.so is linked to the wrong non-NVIDIA library. I had the same issue. For some reason each "yum update" invalidates the link. I have a small bash script that corrects the issue:
# Author: M. Nawijn
# Purpose: Restore symbolic links to NVIDIA libGL* libraries.
# These symbolic links are somehow restored to default
# non-NVIDIA libraries after yum update
# Test for existence of NVIDIA shared libs
if [ -L $nvlibdir/libGL.so ]; then
echo "NVIDIA sharedlibrary exists"
if [ -L $libdir/libGL.so ]; then
echo "OpenGL sharedlibrary exists"
ln -s $nvlibdir/libGL.so $libdir/libGL.so
ln -s %nvlibdir/libGL.so.1 $libdir/libGL.so.1
echo "NVIDIA sharedlibrary links restored."
Thanks for your contribution.
The corresponding issue with ID = OCC22493 has been registered.
Later you can know if the patch is certified and integrated by checking references to the specified ID in OCCT Release Notes.
The issue is clear. You have 64 bit system on which you have also installed the 32bit compatibility opengl libraries while installing the nvidia driver and now the linker is picking up the opengl libraries in /usr/lib instead of /usr/lib64. The solution is simple, you just need to reconfigure with the X include and library path pointing to /usr/lib64.
A Capgemini Group Company
Copyright © 2017 OPEN CASCADE SAS