How to link shared library against alternate version of libGL? - opengl

Question

I built a local version of OpenGL under my home directory. I want to link another shared library against it, but for some reason the linker still links it against the one under /usr/lib, as reported by ldd:
$ cc -o lib/libtfont.so -shared -Wl,-soname,/home/wknight/proj/wkl/tfont.lib/lib/libtfont.so tfont.o -L/home/wknight/proj/wkl/img.lib/lib -limg -L/home/wknight/swtools/opengl/lib -lGL -lGLU
$ ldd lib/libtfont.so
linux-gate.so.1 => (0xb7710000)
/home/wknight/proj/wkl/img.lib/lib/libimg.so (0xb76fc000)
libGL.so.1 => /usr/lib/libGL.so.1 (0xb7689000)
libGLU.so.1 => /usr/lib/libGLU.so.1 (0xb7618000)
libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb74d1000)
libX11.so.6 => /usr/lib/libX11.so.6 (0xb73b4000)
libXext.so.6 => /usr/lib/libXext.so.6 (0xb73a5000)
libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0xb73a0000)
libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0xb739c000)
libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb7397000)
libdrm.so.2 => /usr/lib/libdrm.so.2 (0xb738d000)
libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb7367000)
libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb734e000)
libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7349000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7254000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7236000)
/lib/ld-linux.so.2 (0xb7711000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb721d000)
librt.so.1 => /lib/i686/cmov/librt.so.1 (0xb7214000)
libXau.so.6 => /usr/lib/libXau.so.6 (0xb7211000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb720b000)
$ ls -l /home/wknight/swtools/opengl/lib/libGL*
lrwxrwxrwx 1 wknight wknight 10 Jan 25 16:57 /home/wknight/swtools/opengl/lib/libGL.so -> libGL.so.1
lrwxrwxrwx 1 wknight wknight 12 Jan 25 16:57 /home/wknight/swtools/opengl/lib/libGL.so.1 -> libGL.so.1.2
-rwxr-xr-x 1 wknight wknight 1836469 Jan 25 16:57 /home/wknight/swtools/opengl/lib/libGL.so.1.2
lrwxrwxrwx 1 wknight wknight 11 Jan 25 16:57 /home/wknight/swtools/opengl/lib/libGLU.so -> libGLU.so.1
lrwxrwxrwx 1 wknight wknight 20 Jan 25 16:57 /home/wknight/swtools/opengl/lib/libGLU.so.1 -> libGLU.so.1.3.070900
-rwxr-xr-x 1 wknight wknight 1634905 Jan 25 16:57 /home/wknight/swtools/opengl/lib/libGLU.so.1.3.070900
lrwxrwxrwx 1 wknight wknight 11 Jan 25 16:57 /home/wknight/swtools/opengl/lib/libGLw.so -> libGLw.so.1
lrwxrwxrwx 1 wknight wknight 15 Jan 25 16:57 /home/wknight/swtools/opengl/lib/libGLw.so.1 -> libGLw.so.1.0.0
-rwxr-xr-x 1 wknight wknight 37068 Jan 25 16:57 /home/wknight/swtools/opengl/lib/libGLw.so.1.0.0
$
This happens even if I rename my local version of libGL.so and link against the new name. So something is happening behind the scenes that I don't understand. Is the linker looking in ld.so.cache or something? How can I override it?

Answer 1

I found the answer - I just needed to set LD_LIBRARY_PATH to my local version of libGL.so:
$ export LD_LIBRARY_PATH=$HOME/swtools/opengl/lib
$ ldd lib/libtfont.so
linux-gate.so.1 => (0xb778c000)
/home/wknight/proj/wkl/img.lib/lib/libimg.so (0xb7778000)
libGL.so.1 => /home/wknight/swtools/opengl/lib/libGL.so.1 (0xb771f000)
libGLU.so.1 => /home/wknight/swtools/opengl/lib/libGLU.so.1 (0xb76ae000)
libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7559000)
libX11.so.6 => /usr/lib/libX11.so.6 (0xb743c000)
libXext.so.6 => /usr/lib/libXext.so.6 (0xb742d000)
libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0xb742a000)
libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb7424000)
libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0xb741f000)
libdrm.so.2 => /usr/lib/libdrm.so.2 (0xb7415000)
libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb73fc000)
libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb73f8000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7302000)
libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb72dc000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb72be000)
/lib/ld-linux.so.2 (0xb778d000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb72a5000)
librt.so.1 => /lib/i686/cmov/librt.so.1 (0xb729c000)
libXau.so.6 => /usr/lib/libXau.so.6 (0xb7299000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb7293000)
$
This now makes sense to me when I consider that ldd must use the runtime environment in reporting shared library dependencies, not just what is present in the shared library itself. I would have set LD_LIBRARY_PATH before using some executable linked against the shared library, but it didn't occur to me until now that I must also set it for examining the shared library itself.

Answer 2

I built a local version of OpenGL under my home directory
Why? What is your intention doing this? OpenGL is not so much a library, but a specification. What you built is most likely MesaGL. MesaGL does offer HW accelerated OpenGL only with a certain subset of drivers, which also must match your very MesaGL version. Without them, MesaGL will drop into a slow software rasterizer fallback.
As a general rule you always link your program dynamically to the system's libGL.so. If there's no libGL.so present shipping a fallback implementation makes sense only if you can deal with a very slow software rasterizer. Otherwise I'd be better to just inform the user about his systems shortcomings and that either a better GPU must be installed, or the driver installation fixed.
Anyway, if you want to change the path a library is searched in, you should look into the rpath linker flag.