gcc complains about not finding Opengl

Jan 2, 2021 at 1:02am
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?
Jan 2, 2021 at 3:03am
colt wrote:
The final part of the gcc invocation shows it's looking for it in the correct place: -L/usr/lib/mesa -lGL


Just a guess at this stage:

Can you please post the entire line of that command? Order is important, the library spec should come before the source code files that uses it.
Jan 2, 2021 at 3:17am
the library spec should come before the source code files that uses it

You mean after, not before.
Last edited on Jan 2, 2021 at 3:18am
Jan 3, 2021 at 1:33am
@dutch

Yeah my bad.

But I wonder if the OP has their library spec after the -o output file flag - that wouldn't work?

@colt

Could post the whole command?
Jan 7, 2021 at 3:10pm
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.
Jan 7, 2021 at 11:47pm
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.
Jan 8, 2021 at 6:12am
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.
Topic archived. No new replies allowed.