Ld: cannot find -lGL (centos 7)

when I try to sudo make (or just make)
for the glew-1.13.0 tarball which I extracted
I get a link error /bin/ld: cannot find -lGL

-L/usr/lib64 is in the cc command

I used yum to install mesa-libGL-devel and mesa-libGLU-devel,
and if I run it again it says both are “already installed and latest version”.
I am able to run /usr/bin/glxinfo and glxinfo64
and if I do ldd /usr/bin/glxinfo it shows
libGL.so.1

And indeed in /usr/lib64 I see the symlinks libGL.so and libGL.so.1 and the real file libGL.so.355.11 (and also libGL.la)

Any ideas what’s going on? Thanks, Colin

I’m fairly sure that libGL.so.355.11 is the nVidia version, not the Mesa version.

What does


ls -l /usr/lib64/libGL.so
ldd /usr/lib64/libGL.so

show?

Other than that, I’d suggest checking the CentOS (or RHEL) documentation regarding installing OpenGL. This kind of issue tends to be quite specific to a particular distribution and version.

these return:


$ ls -l /usr/lib64/libGL.so
lrwxrwxrwx. 1 root root 14 Jul 14 16:34 /usr/lib64/libGL.so -> libGL.so.1.2.0                                            
$ ldd /usr/lib64/libGL.so
ldd: /usr/lib64/libGL.so: No such file or directory
$ ldd /usr/lib64/libGL.so.1.2.0
ldd: /usr/lib64/libGL.so.1.2.0: No such file or directory

Does that clarify anything?

If the linker is referring to the symbolic link file libGL.so (via -lGL compiler flag) does it care which version of the real library is present? I would assume the latest nvidia version for my specific GPU ought to be desirable…?
Thanks.

Yes. libGL.so is a dangling symlink (i.e. it references a file which doesn’t exist).

[QUOTE=colinrein;1283296]
If the linker is referring to the symbolic link file libGL.so (via -lGL compiler flag) does it care which version of the real library is present? I would assume the latest nvidia version for my specific GPU ought to be desirable…?[/QUOTE]
The linker uses the libGL.so symlink to open the library. This doesn’t exist, which is the root of your problem.

The fact that you have an actual library doesn’t matter if the libGL.so symlink doesn’t refer to it.

If you’re using the proprietary nVidia driver, you should probably remove mesa and mesa-devel and install the nVidia package and its associated -devel package.

The resulting executable ought to work with either, but the -devel package must match the run-time library.

[QUOTE=GClements;1283297]Yes. libGL.so is a dangling symlink (i.e. it references a file which doesn’t exist).
The linker uses the libGL.so symlink to open the library. This doesn’t exist, which is the root of your problem.
[/QUOTE]
Would it work to just update the symlink to point to the nvidia version libGL.so.355.11 ?

Also, shouldn’t the correct library versions for the mesa packages have been installed when I used yum to install those?

[QUOTE=colinrein;1283298]Would it work to just update the symlink to point to the nvidia version libGL.so.355.11 ?
[/QUOTE]
Probably. But it ought to be possible to get this working using the package manager, and that should be preferred. So you should first try uninstalling all related packages then reinstalling only the correct ones. And read any applicable documentation first. There may be other factors beside the symlink.

I would have thought that it would have refused to install both -devel packages at the same time, and possibly refused to install both runtime packages.

Well this Nvidia devtalk post fixed my error: the libGL.so symlink was dangling (as you said GClements),
so I deleted and recreated symlink libGL.so pointing to libGL.so.1 which points to libGL.so.355.11
not sure what broke it.

https://devtalk.nvidia.com/default/topic/928174/opengl/-usr-bin-ld-cannot-find-lgl-collect2-error-ld-returned-1-exit-status/

thanks for the help!

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.