Qt creator linux не видит библиотеки

Обновлено: 30.06.2024

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

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

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

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

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

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

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

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

INCLUDEPATH *= E:/DebugLibrary/VTK E:/DebugLibrary/VTK/Common E:/DebugLibrary/VTK/Filtering E:/DebugLibrary/VTK/GenericFiltering E:/DebugLibrary/VTK/Graphics E:/DebugLibrary/VTK/GUISupport/Qt E:/DebugLibrary/VTK/Hybrid E:/DebugLibrary/VTK/Imaging E:/DebugLibrary/VTK/IO E:/DebugLibrary/VTK/Parallel E:/DebugLibrary/VTK/Rendering E:/DebugLibrary/VTK/Utilities E:/DebugLibrary/VTK/VolumeRendering E:/DebugLibrary/VTK/Widgets 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-lvtkfreetype lqvtkwidgetplugin-lvtkgenericfiltering

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

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

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

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

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

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

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

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

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

Я хотел бы добавить для полноты, что вы также можете добавить только путь к библиотеке, где он будет искать зависимую библиотеку (на которую может не быть прямой ссылки в вашем коде, но библиотека, которую вы используете, может понадобиться).

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

путь, которым я обошел это, следующий:

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

Установлен Qt 5.8.0.
Проблема появилась ещё в R8, в R7 все нормально.
Проблема именно на 64-битной версии, на 32-битной этой проблемы нет.
Нужные заголовочники-либы установленны! Программа компилируется, просто Qt не хочет их видеть.

Проблема явно не в Qt, пробовал разные версии, опять же повторю - R7 все нормально, так же как и в 32-битной версии, в OpenSUSE все нормально, проблема где то в ROSA.
Только не предлагайте скопировать в папку Qt все заголовочники, этот кустарный метод хоть и сработает но это сами понимаете что так не должно быть, Qt не хочет с системы подхватывать заголовочники.

Как решить эту проблему?

Всмысле не правильно? На более старых роса да и на suse, все работает, а тут я значит путь не правильно указываю? Почему эта ошибка появилась ещё в роса r8, эта проблема только в роса в других дистрах и старых росах такой чуши нет.

Qt всегда сам из системы все подхватывал, повторю ещё раз: эта фигня появилась ещё в ROSA R8 на 64-битной версии, на 32-битных все само подхватывает из системы так как это и должно быть в принципе.

Можете по подробнее?

Последний раз редактировалось Satana_00 30 апр 2017, 22:51, всего редактировалось 1 раз. Особенность Мандривы/Росы в том, что 64-битные либы называются как lib64qt*-devel, а не libqt*-devel. Может быть, в этом дело? Сила воли — это масса воли умноженная на ускорение воли. Особенность Мандривы/Росы в том, что 64-битные либы называются как lib64qt*-devel, а не libqt*-devel. Может быть, в этом дело?

Причем здесь lib64qt*-devel, если речь идет о встроенных либах с++, Qt все свое прекрасно видит.
Ведь в R7 небыло такой чуши и все прекрасно было.

------------
Нужно было мне сразу в тексте написать подробнее а не скриншотом часть проблемы показывать)))), я имею ввиду именно инклуды плюсов.
------------

Последний раз редактировалось Satana_00 30 апр 2017, 22:57, всего редактировалось 1 раз. библиотеки находятся в /lib64 и /usr/lib64, без указания пути ищет в /lib tverskoy писал(а): библиотеки находятся в /lib64 и /usr/lib64, без указания пути ищет в /lib Qt 64-битный и ищет он там где надо. Обратите внимание на скриншот.

Satana_00 писал(а): Установлен Qt 5.8.0.
Проблема появилась ещё в R8, в R7 все нормально.
Проблема именно на 64-битной версии, на 32-битной этой проблемы нет.
Нужные заголовочники-либы установленны! Программа компилируется, просто Qt не хочет их видеть.

Как решить эту проблему?

У меня на R8.1 проблемы такой нету. Даже переход по F2 работает. В R9 действительно баг есть. Проверил на свежеустановленной системе. А напишите точный порядок воспроизведения ошибки. Программы-то в репозиториях как-то собрались, значит компилятор все нашел. keleg писал(а): А напишите точный порядок воспроизведения ошибки. Программы-то в репозиториях как-то собрались, значит компилятор все нашел.

Речь идет не про компилятор, а про IDE (qt-creator). IDE не видит системных заголовочных файлов, например iostream.

Воспроизвести просто. Объявите любую системную библиотеку (не Qt, а из C++) и посмотрите как IDE себя поведет. Будет ли она давать подсказки из этого файла?

Сравните результаты с IDE которая была в R8.1 (возможно на чистом R8.1 такой же баг, так что лучше на R7)

Еще раз обращаю внимание, что речь идет только о IDE. В при самой сборке все include подключаются корректно. Точнее, на том примере что я тестировал. Пока, к сожалению, R9 не пользуюсь, не могу точно сказать где еще проявляется баги, я только пытаюсь помочь автору этого топика. Ну и конечно же мне это тоже в последствии скажется.

int sample(mglGraph *gr, void *)
return 0;
>

int main (int argc, char **argv)
QApplication a(argc, argv);
QMathGL *test = new QMathGL;

Друга:
.pro:
QT += core gui

LIBS += -L/usr/local/lib -lmgl

TARGET = mathgltest
TEMPLATE = app

int main(int argc, char* argv[])
//Qt startup
QApplication a(argc, argv);

//Using MathGL to write a plot to file
mglGraphZB plot;
plot.Alpha(true);
plot.Light(true);
plot.Light(0,mglPoint(1,0,-1));
mglData data(2,2);
data.Modify("x*y");
plot.Axis(mglPoint(0,0,0),mglPoint(1,1,1));
plot.Rotate(80,40);
plot.Surf(data);
plot.Box();
plot.Puts(mglPoint(0.7,1,1.2),"a(x,y)");
plot.WriteBMP("CppMathGlExample1.bmp");

//Use Qt to display the saved plot
QDialog dialog;
QVBoxLayout layout;
QPixmap pixmap("CppMathGlExample1.bmp");
QLabel label;
label.setPixmap(pixmap);
layout.addWidget(&label);
dialog.setLayout(&layout);
dialog.show();
return a.exec();
>
@
Друг собирал сам из исходников.
У него последний SDK, Mac OS X Snow Leopard 10.6.8.

Ну в общем почему так? Как вообще правильно подключать любую библиотеку?

И еще вопрос: можно ли в QtCreator 2.2.1 (или вообще в mingw) добавить дефолтные пути к поиску хедеров и либ?

ПКМ в .pro файле -> Добавить библиотеку. В появившемся мастере выбираем нужные пункты.
После этого библиотека должна автоматически прописаться.
Теперь работает?

Другу помогло, а вот мне нет. Там везде формат .a у библиотек, у меня их не видит мастер.

У вас должны быть .lib или .dll
Может вы не то скачали?
Вы динамически хотите подключать или статически?

Нашел их, зачем-то это все в bin суют, а не в lib. Мастер правда только lib хочет, но уже руками дописать смог. Спасибо!

Посмотри на вывод линкера.
Он там, по идее, должен писать имя ожидаемой библиотеки. Проверь имена своих файлов.

Для ситуации:
LIBS += -L/usr/local/lib -lmgl
он, насколько я помню, ищет файл:
/usr/local/lib/libmgl.a или
/usr/local/lib/libmgl.so

В общем, имя файла, который подключает отличается от того, что пишешь в Pro-файле.
Хотя для VC++ и Windows у меня такого нет.
Пример:
unix LIBS += -L../libs -lprotobuf
>else LIBS += -L../libs -llibprotobuf
>

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

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

INCLUDEPATH *= E:/DebugLibrary/VTK E:/DebugLibrary/VTK/Common E:/DebugLibrary/VTK/Filtering E:/DebugLibrary/VTK/GenericFiltering E:/DebugLibrary/VTK/Graphics E:/DebugLibrary/VTK/GUISupport/Qt E:/DebugLibrary/VTK/Hybrid E:/DebugLibrary/VTK/Imaging E:/DebugLibrary/VTK/IO E:/DebugLibrary/VTK/Parallel E:/DebugLibrary/VTK/Rendering E:/DebugLibrary/VTK/Utilities E:/DebugLibrary/VTK/VolumeRendering E:/DebugLibrary/VTK/Widgets 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-lvtkfreetype lqvtkwidgetplugin-lvtkgenericfiltering

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

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

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

путь, которым я обошел это, следующий:

Вот реализация, которую я нахожу очень универсальной:

Правильный способ сделать это выглядит следующим образом:

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

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

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

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

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

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

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

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

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

Читайте также: