У меня есть две библиотеки libGL на той же машине Ubuntu 11.04. Одна библиотека была установлена для видеокарты Nvidia по адресу /usr/lib/libGL.so, другая по умолчанию установлена с Ubuntu, расположенной по адресу usr/lib/x86_64-linux-gnu/mesa/libGL.so.Переопределение выбора OpenGL Qt 4.8.1
Теперь у меня проблема - это библиотека Qt, загружаемая из репозиториев Ubuntu в отношении библиотеки mesa, но я хочу связать ее с библиотекой Nvidia. Это, вероятно, даст лучшую производительность, и при компиляции программы возникли проблемы с использованием libGL mesa. Те, которые были зафиксированы:
export LIBGL_ALWAYS_INDIRECT=1
Насколько мне известно, это заставляет X11 выбрать библиотеку OpenGL, и он выбирает правильный. Но, скорее всего, Qt и программа, скомпилированная с QtOpenGL, будут напрямую связываться с правильной библиотекой.
Я скачал 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, существует ли способ установить приоритет библиотек, которые использует компоновщик?
В худшем случае, я мог бы, вероятно, изменить все Make-файлы после запуска ./configure. Grep все дерево Qt для использования -lGL и измените его на /usr/lib/libGL.so. Я чувствую, что это довольно хак.
Update
Некоторый успех. Я сделал grep на дереве Qt для lGL и обнаружил, что другие mkspecs (кроме linux-g++-64) использовали другие переменные для указания пути OpenGL. Поэтому я добавил их mkspec linux-g++-64 «s, вот результат mkspec/linux-g++-64/qmake.conf:
QMAKE_LIBS_OPENGL = /usr/lib/libGL.so
QMAKE_LIBS_OPENGL_QT = /usr/lib/libGL.so
Так что я установить путь к библиотеке я хотел сразу думать, что это будет правильно связать. Действительно, это была хорошая новость, во время компиляции -lGL никогда не использовался. Тем не менее, конечный результат был lib/libQtOpenGL.so все еще связан с неправильной библиотекой:
$ 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, а проблема компоновщика.
Есть ли способ с ldconfig или другими инструментами, чтобы указать, к какой библиотеке обращаться, если -lGL? Я знаю, что в других библиотеках есть программа, которая будет организовывать какую библиотеку использовать (libusb-config подходит для моего), но я не думаю, что это так в openGL.