Home/ Questions/Q 6940031
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-27T12:42:06+00:00

I’m compiling a shared library, with a -lGL on the ld command. But it

  • 0

I’m compiling a shared library, with a -lGL on the ld command. But it can’t find the libGL.so on my system. Nvidia package correctly set libraries path in /etc/ld.so.conf.d/.
Even the output of ldconfig -p | grep libGL.so found it:

libGL.so.1 (libc6,x86-64) => /usr/lib/nvidia-current/libGL.so.1
libGL.so.1 (libc6) => /usr/lib32/nvidia-current/libGL.so.1
libGL.so (libc6,x86-64, OS ABI: Linux 2.4.20) => /usr/lib/x86_64-linux-gnu/libGL.so
libGL.so (libc6,x86-64) => /usr/lib/nvidia-current/libGL.so
libGL.so (libc6, OS ABI: Linux 2.4.20) => /usr/lib32/libGL.so
libGL.so (libc6) => /usr/lib32/nvidia-current/libGL.so

I read almost everywhere that to be able to link with it, i have basically 2 solutions:

  1. Link the nvidia libGL.so to a standard /usr/lib location. That seem wrong for anybody what will try to compile an opengl library. Why the linker is not using the ldconfig cache ?

  2. Append manually the -L/usr/lib/nvidia-current to the library search path. Again, wrong, how can i know every path where the library could be found on all the system ?

So my real question is: What is the standard and automatic approach for linking with a library not in a standard location, but location already register with /etc/ld.so.conf ?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    /etc/ld.so.conf is used by /lib/ld.so to resolve shared libraries at runtime, it has nothing to do with linking stuff at compile time.

    What is the right way to do is just linking to libGL.so in /usr/lib/x86_64-linux-gnu/ and the application will use the nvidia’s libGL.so on runtime. This shouldn’t be a problem because the OpenGL interface is stable and symbols are the same in both libraries, its the implementation that is different.

    • 0