I have two different libGL libraries on the same Ubuntu 11.04 machine. One library was installed for the Nvidia’s graphics card at /usr/lib/libGL.so the other is the default that came installed with Ubuntu, located at usr/lib/x86_64-linux-gnu/mesa/libGL.so.
Now, the problem I have is the Qt library downloaded from Ubuntu’s repositories links against the mesa library, but I want to link against Nvidia’s library. This will probably give better performance, and there have been issues using mesa’s libGL when compiling a program. Those have been fixed by:
export LIBGL_ALWAYS_INDIRECT=1
To my knowledge this forces X11 to choose the openGL library, and it is choosing the correct one. But, I would much rather have Qt and the program that is compiled with QtOpenGL be linking directly with the correct library.
I downloaded Qt and compiled it myself using these options:
./configure -nomake examples -nomake demos -nomake tools -release -no-webkit
I hoped the linker would use the correct library. No dice. Next, I tried editing the mkspec/linux-g++-64/qmake.conf with these variables set:
QMAKE_LIBDIR_X11 = /usr/lib/x86_64-linux-gnu
QMAKE_LIBDIR_OPENGL = /usr/lib
Is there an option where I can force the linking of a specific library instead of another (specifically when the configure script is run)? I would prefer not to configure the linker in any specific way. I would also rather not remove the mesa library.
If there is no such configure script flag to do so, is there a way to set precedence of libraries the linker uses?
Worst case scenario, I could probably change all the Makefiles after ./configure is run. Grep the entire Qt tree for use of -lGL and change it to /usr/lib/libGL.so. I feel this is quite a hack though.
Update
Some success. I did a grep on the Qt tree for lGL and found that other mkspecs (besides linux-g++-64) used other variables to specify OpenGL path. So I added them to linux-g++-64‘s mkspec, here’s the result of mkspec/linux-g++-64/qmake.conf:
QMAKE_LIBS_OPENGL = /usr/lib/libGL.so
QMAKE_LIBS_OPENGL_QT = /usr/lib/libGL.so
So I set the path to the library I wanted directly thinking it would link properly. Indeed it was good news, during the compilation, -lGL was never used. However, the ultimate result was lib/libQtOpenGL.so is still linked with the wrong library:
$ ldd lib/libQtOpenGL.so
linux-vdso.so.1 => (0x00007fffd83ff000)
libQtGui.so.4 => (edited)lib/libQtGui.so.4 (0x00007f554c684000)
libQtCore.so.4 => (edited)lib/libQtCore.so.4 (0x00007f554c19c000)
libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007f554beda000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f554bcd6000)
**libGL.so.1 => /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1 (0x00007f554ba7a000)**
libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x00007f554b86e000)
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f554b536000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f554b22f000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f554afaa000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f554ad94000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f554a9f5000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f554a7d7000)
libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007f554a4e1000)
libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 (0x00007f554a2ba000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f554a0a1000)
libSM.so.6 => /usr/lib/x86_64-linux-gnu/libSM.so.6 (0x00007f5549e99000)
libICE.so.6 => /usr/lib/x86_64-linux-gnu/libICE.so.6 (0x00007f5549c7f000)
libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1 (0x00007f5549a48000)
libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f5549835000)
libgthread-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgthread-2.0.so.0 (0x00007f554962f000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f5549427000)
/lib64/ld-linux-x86-64.so.2 (0x00007f554d66f000)
libglapi.so.0 => /usr/lib/x86_64-linux-gnu/libglapi.so.0 (0x00007f5549203000)
libXdamage.so.1 => /usr/lib/x86_64-linux-gnu/libXdamage.so.1 (0x00007f5548fff000)
libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007f5548df9000)
libXxf86vm.so.1 => /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1 (0x00007f5548bf3000)
libdrm.so.2 => /usr/lib/x86_64-linux-gnu/libdrm.so.2 (0x00007f55489e7000)
libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f55487cb000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f554858e000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007f5548389000)
libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f554815f000)
libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f5547f5b000)
libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f5547d55000)
I have no idea why, I specified directly what library to use and it was passed correctly to g++, but the linker apparently ignored it. I believe it is no longer a Qt problem, but a linker problem.
Is there any way with ldconfig or other tools to specify what library to link to in case of -lGL? I know other libraries have a program which will organize what library to use (libusb-config comes to mine), but I do not think this is the case with openGL.
The linker needs reconfigured to find the correct library for openGL. One such option, often frowned upon is changing the
LD_LIBRARY_PATHvariable to include the path of the openGL library that you wish you use. In my case it was located at/usr/libso I changed the variable accordingly.export LD_LIBRARY_PATH=/usr/lib/fsl/4.1:/usr/libAfter running the
./configurescript with the same options and making it, it was finally pointing to the correct library.I believe there is one other possible and probably better alternative. With Ubuntu 11.04, the linker is configured to look in the
/usr/lib/x86_64-linux-gnu/mesa/directory with a configuration file located at/etc/ld.so.conf.d/x86_64-linux-gnu_GL.conf.If this file is edited to reflect a different path, the linker will probably choose that library instead. It appears that the linker’s library search priority is:
LD_LIBRARY_PATH=> files located in/etc/ld.so.conf.d=> Finally resorting to searching for libraries in default paths.It is probably a better solution to edit the files accordingly in /etc/ld.so.conf.d, but in my case I do not have the privileges to edit those files so editing
LD_LIBRARY_PATHdid the trick.