Overriding Qt 4.8.1's OpenGL Selection
-
12-06-2021 - |
Domanda
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.
Soluzione
The linker needs reconfigured to find the correct library for openGL. One such option, often frowned upon is changing the LD_LIBRARY_PATH
variable to include the path of the openGL library that you wish you use. In my case it was located at /usr/lib
so I changed the variable accordingly.
export LD_LIBRARY_PATH=/usr/lib/fsl/4.1:/usr/lib
After running the ./configure
script with the same options and making it, it was finally pointing to the correct library.
ldd lib/libQtOpenGL.so
linux-vdso.so.1 => (0x00007fff04ebf000)
libQtGui.so.4 => (edited)Qt4.8.1/lib/libQtGui.so.4 (0x00007fad8826c000)
libQtCore.so.4 => (edited)Qt4.8.1/lib/libQtCore.so.4 (0x00007fad87d84000)
libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007fad87ac2000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fad878be000)
**libGL.so.1 => /usr/lib/libGL.so.1 (0x00007fad875a8000)**
libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x00007fad8739c000)
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007fad87064000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fad86d5d000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fad86ad8000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fad868c2000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fad86523000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fad86305000)
libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007fad8600f000)
libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 (0x00007fad85de8000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fad85bcf000)
libSM.so.6 => /usr/lib/x86_64-linux-gnu/libSM.so.6 (0x00007fad859c7000)
libICE.so.6 => /usr/lib/x86_64-linux-gnu/libICE.so.6 (0x00007fad857ad000)
libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1 (0x00007fad85576000)
libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007fad85363000)
libgthread-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgthread-2.0.so.0 (0x00007fad8515d000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fad84f55000)
/lib64/ld-linux-x86-64.so.2 (0x00007fad89257000)
libnvidia-tls.so.290.10 => /usr/lib/tls/libnvidia-tls.so.290.10 (0x00007fad84d52000)
libnvidia-glcore.so.290.10 => /usr/lib/libnvidia-glcore.so.290.10 (0x00007fad82a4a000)
libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007fad8282e000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fad825f1000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007fad823ec000)
libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007fad821c2000)
libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007fad81fbe000)
libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007fad81db8000)
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_PATH
did the trick.