Hello. I am trying to compile a c++/c project. During the first attempts, it became clear that it was not finding the necessary libraries.
Then I decided to edit the Makefile and the other associated file (a pre makefile) to assure that gcc/g++ would find it. It worked for libpng, but is not working for libGl.
Originally, it was looking for it on /usr/X11R6/lib which does not exist on my system. Then I replaced it by its correct place which is: /usr/lib/mesa/
yet when sending make to do its job, I receive
1 2
/usr/bin/ld: cannot find -lGL
collect2: error: ld returned 1 exit status
The final part of the gcc invocation shows it's looking for it in the correct place: -L/usr/lib/mesa -lGL
Running ls on /usr/lib/mesa/ shows ld.so.conf libGL.so.1 libGL.so.1.2
So could anyone help me to shed some light in this strange behavior?
Do you have separate "dev" packages that you have not installed?
I would guess that the base package for a library "FFF" contains file
"libFFF.so.x.y" and symbolic link "libFFF.so.x" that points to "libFFF.so.x.y".
Then there might be a separate package *-dev, *-devel, etc
that provides:
1. Header files for FFF that your code will include
2. "libFFF.so" that is a symbolic link to "libFFF.so.x.y".
(3. Optionally "libFFF.a" for static linking.)
The -lGL most likely makes the linker to look for libGL.so.
However, it will dereference link and/or read version from the library
so that the binary will require libGL.so.1 during runtime.
Ok, the I found the error with the help you the latest post: There was no libGL.so, only the symbolic link libGL.so.1 and the actual library libGL.so.1.2. So I created a new symbolic link libGL.so pointing to libGL.so.1.2 and solved it.
If your system has package management, then you should be able to solve the issue by installing appropriate package, rather than by creating a file that the package manager does not know about.