Добавление внешней библиотеки в проект Qt Creator - PullRequest
103 голосов
/ 05 апреля 2009

Как добавить внешнюю библиотеку в проект, созданный Qt Creator RC1 (версия 0.9.2)? Например, функция win32 EnumProcesses() требует добавления Psapi.lib в проект для сборки.

Ответы [ 8 ]

208 голосов
/ 25 апреля 2009

Правильный способ сделать это так:

LIBS += -L/path/to -lpsapi

Таким образом, он будет работать на всех платформах, поддерживаемых Qt. Идея состоит в том, что вы должны отделить каталог от имени библиотеки (без расширения и без префикса 'lib'). Конечно, если вы используете специфичную для Windows библиотеку, это действительно не имеет значения.

Если вы хотите сохранить ваши lib-файлы в каталоге проекта, вы можете ссылаться на них с помощью переменной $$_PRO_FILE_PWD_, например ::

LIBS += -L"$$_PRO_FILE_PWD_/3rdparty/libs/" -lpsapi
22 голосов
/ 05 апреля 2009

Вы используете qmake проекты? Если это так, вы можете добавить внешнюю библиотеку, используя переменную LIBS. Например:

win32:LIBS += path/to/Psapi.lib
11 голосов
/ 19 ноября 2009

LIBS + = C: \ Program Files \ OpenCV \ lib

не будет работать, потому что вы используете пробелы в Program Files. В этом случае вам нужно добавить кавычки, чтобы результат выглядел так: LIBS + = "C: \ Program Files \ OpenCV \ lib" Я рекомендую размещать библиотеки не в местах с пробелами; -)

6 голосов
/ 21 апреля 2009

Вы имеете в виду ошибку из-за отсутствия дополнительного пути включения. Попробуйте добавить его с помощью: INCLUDEPATH + = C: \ path \ to \ include \ files \ Надеюсь, что это работает. С уважением.

4 голосов
/ 26 декабря 2012

А чтобы добавить несколько библиотечных файлов, вы можете написать так:

INCLUDEPATH * = E: / DebugLibrary / VTK E: / DebugLibrary / VTK / Common E: / DebugLibrary / VTK / Фильтрация E: / DebugLibrary / VTK / GenericFiltering E: / DebugLibrary / VTK / Графика E: / DebugLibrary / VTK / GUISupport / Qt E: / DebugLibrary / VTK / Hybrid E: / DebugLibrary / VTK / Imaging E: / DebugLibrary / VTK / IO E: / DebugLibrary / VTK / Parallel E: / DebugLibrary / VTK / Рендеринг E: / DebugLibrary / VTK / Утилиты E: / DebugLibrary / VTK / VolumeRendering E: / DebugLibrary / VTK / Виджеты E: / DebugLibrary / VTK / Wrapping

LIBS * = -LE: / DebugLibrary / VTKBin / bin / release -lvtkCommon -lvtksys -lQVTK -lvtkWidgets -lvtkRendering -lvtkGraphics -lvtkImaging -lvtkIO -lvtkFiltering -lvtkDICOMParser -lvtkpng -lvtktiff -lvtkzlib -lvtkjpeg -lvtkexpat -lvtkNetCDF -lvtkexoIIc -lvtkftgl -lvtkfreetype -lvtkHybrid -lvtkVolumeRendering -lQVTKWidgetPlugin -lvtkGenericFiltering

3 голосов
/ 20 августа 2015

Если вы хотите развернуть свое приложение на компьютерах клиентов, а не использовать ваше приложение только самостоятельно, мы обнаружим, что метод LIBS+= -Lxxx -lyyy может привести к путанице, если не к проблемам.

Мы разрабатываем приложения для Linux, Mac и Windows, используя Qt. Мы отправляем полные, автономные приложения. Таким образом, все несистемные библиотеки должны быть включены в пакет развертывания. Мы хотим, чтобы наши клиенты могли запускать приложение с одного USB-накопителя для всех ОС. Из соображений совместимости платформы USB-накопитель должен быть отформатирован как FAT32, который не поддерживает символические ссылки (Linux).

Мы нашли идиому LIBS+= -Lxxx -lyyy слишком большой для черного ящика:

  1. Мы точно не знаем, что такое filepath библиотеки (статической или динамической), найденной компоновщиком. Это неудобно. Наш компоновщик Mac регулярно находил библиотеки, отличные от тех, которые, как мы думали, следует использовать. Это происходило несколько раз с библиотеками OpenSSL, где компоновщик Mac обнаруживал и использовал свою собственную - более старую, несовместимую - версию OpenSSL, а не нашу запрашиваемую версию.

  2. Мы не можем позволить, чтобы компоновщик использовал символические ссылки на библиотеки, поскольку это нарушило бы пакет развертывания.

  3. Мы хотим видеть из имени библиотеки, связываем ли мы статическую или динамическую библиотеку.

Так что для нашего конкретного случая мы используем только абсолютные пути к файлам и проверяем, существуют ли они. Мы удаляем все символические ссылки.

Сначала мы выясним, какую операционную систему мы используем, и поместим это в переменную CONFIG. И, например, для Linux 64bit, тогда:

linux64 {
    LIBSSL= $$OPENSSLPATH/linux64/lib/libssl.a
    !exists($$LIBSSL): error ("Not existing $$LIBSSL")
    LIBS+= $$LIBSSL
    LIBCRYPTO= $$OPENSSLPATH/linux64/lib/libcrypto.a
    !exists($$LIBCRYPTO): error ("Not existing $$LIBCRYPTO")
    LIBS+= $$LIBCRYPTO
}

Все зависимости могут быть скопированы в пакет развертывания, поскольку мы знаем их пути к файлам.

1 голос
/ 26 мая 2016

Я хотел бы добавить для полноты картины, что вы также можете добавить только ПУТЬ БИБЛИОТЕКИ, где он будет искать зависимую библиотеку (на которую может не ссылаться напрямую ваш код, но может понадобиться используемая вами библиотека).

Для сравнения, это будет соответствовать тому, что делает среда LIBPATH, но его вид неясен в Qt Creator и недостаточно документирован.

То, как я пришел к этому, таково:

LIBS += -L"$$_PRO_FILE_PWD_/Path_to_Psapi_lib/"

По сути, если вы не укажете фактическое имя библиотеки, она добавит путь, по которому она будет искать зависимые библиотеки. Разница в синтаксисе невелика, но это очень полезно для предоставления только PATH, где искать зависимые библиотеки. Иногда бывает просто задавать каждый путь отдельной библиотеке, в которой вы знаете, что они все находятся в определенной папке, и Qt Creator подберет их.

0 голосов
/ 14 декабря 2018

in .pro: LIBS += Ole32.lib OleAut32.lib Psapi.lib advapi32.lib

in .h / .cpp: #pragma comment(lib,"user32.lib")

#pragma comment(lib,"psapi.lib")
...