覆盖Qt 4.8.1'；s OpenGL选择

我在同一台Ubuntu11.04机器上有两个不同的libGL库。一个库安装在Nvidia图形卡的

/usr/lib/libGL。因此

另一个库是Ubuntu附带的默认库，位于

usr/lib/x86_64-linux-gnu/mesa/libGL.so

现在，我遇到的问题是从Ubuntu的存储库下载的Qt库与mesa库的链接，但我想与Nvidia库的链接。这可能会提供更好的性能，并且在编译程序时使用mesa的libGL会出现问题。这些问题已通过以下方式解决：

export LIBGL_ALWAYS_INDIRECT=1

据我所知，这迫使X11选择openGL库，而且它正在选择正确的库。但是，我更愿意让Qt和用QtOpenGL编译的程序直接链接到正确的库

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)

我下载了Qt，并使用以下选项自行编译：

./configure -nomake examples -nomake demos -nomake tools -release -no-webkit

我希望链接器使用正确的库。没有骰子。接下来，我尝试编辑设置了以下变量的

mkspec/linux-g++-64/qmake.conf

：

QMAKE_LIBDIR_X11      = /usr/lib/x86_64-linux-gnu
QMAKE_LIBDIR_OPENGL   = /usr/lib

是否有一个选项可以强制链接特定库而不是另一个库（特别是在运行配置脚本时）？我不希望以任何特定的方式配置链接器。我也不希望删除mesa库

如果没有这样的配置脚本标志，是否有方法设置链接器使用的库的优先级

最坏的情况是，我可能会在运行

/configure

后更改所有的makefile。Grep整个Qt树以使用

-lGL

，并将其更改为

/usr/lib/libGL.so

。不过，我觉得这是一个相当棘手的问题

更新

有些成功。我对lGL的Qt树进行了grep，发现其他mkspec（除了

linux-g++-64

）使用了其他变量来指定OpenGL路径。因此，我将它们添加到

linux-g++-64

的mkspec中，下面是

mkspec/linux-g++-64/qmake.conf

的结果：

QMAKE_LIBS_OPENGL     = /usr/lib/libGL.so
QMAKE_LIBS_OPENGL_QT  = /usr/lib/libGL.so

因此，我设置了指向我想要的库的路径，直接认为它可以正确链接。事实上，这是个好消息，在编译过程中，-lGL从未被使用过。但是，最终的结果是

lib/libQtOpenGL。因此

仍然与错误的库链接：

$ 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)

我不知道为什么，我直接指定了要使用的库，并将它正确地传递给

g++

，但链接器显然忽略了它。我相信这不再是一个Qt问题，而是一个链接器问题

---

如果出现

-lGL

，是否可以使用

ldconfig

或其他工具指定要链接到哪个库？我知道其他库有一个程序可以组织要使用的库（

libusb-config

来找我），但我认为openGL不是这样。

链接器需要重新配置才能找到正确的openGL库。其中一个经常被反对的选项是更改

LD_LIBRARY_PATH

变量，以包含希望使用的openGL库的路径。在我的例子中，它位于

/usr/lib

，因此我相应地更改了变量

export-LD\u-LIBRARY\u-PATH=/usr/lib/fsl/4.1:/usr/lib

在使用相同的选项运行

/configure

脚本并使其生效后，它最终指向了正确的库

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)

我相信还有另外一种可能的、可能更好的选择。在Ubuntu 11.04中，链接器被配置为查看

/usr/lib/x86_64-linux-gnu/mesa/

目录，配置文件位于

/etc/ld.so.conf.d/x86_64-linux-gnu GL.conf

如果编辑此文件以反映不同的路径，则链接器可能会选择该库。链接器的库搜索优先级似乎为：

LD\u LIBRARY\u PATH

=>位于

/etc/LD.so.conf.d

=>中的文件最终求助于在默认路径中搜索库

在/etc/ld.so.conf.d中相应地编辑文件可能是一个更好的解决方案，但在我的情况下，我没有编辑这些文件的权限，因此编辑

ld\u LIBRARY\u PATH

起了作用