Подключение libusb-1.0 к Qt (MinGW) в Windows 8

[flammmable]

Добрый день!
Пытаюсь соединить устройство (STM32-Nucleo) с компьютером.
Для этого я скачал с офф.сайтов Qt-5.7.0 с MinGW-5.3.0 и библиотеку libusb-1.0.20.

Структура папок libusb-1.0 следующая

libusb-1.0.20
    examples
    include
        libusb-1.0
            libusb.h
    MinGW32
        dll
            libusb-1.0.dll
            libusb-1.0.dll.a
        static
            libusb-1.0.a
    MinGW64
    MS32
    MS64
    libusb-1.0.def
    README.txt

1. я создал чистый проект
2. добавил в .pro

Код:

INCLUDEPATH += C:\Qt\libusb-1.0.20\include\libusb-1.0\
LIBS += C:\Qt\libusb-1.0.20\MinGW32\static\libusb-1.0.a

3. добавил в main.cpp

Код:

#include <libusb.h>

(автоподстановщик начал подсказывать имена функций из libusb)
4.  добавил вызов libusb_init(NULL);

Код:

int main(int argc, char *argv[])
{
    libusb_init(NULL);

    QApplication a(argc, argv);
    MainWindow w;
    w.show();

    return a.exec();
}

Но. При компиляции возникает ошибка:
In function `Z5qMainiPPc':
undefined reference to `libusb_init@4'

Что я делаю не так?

[PimenS]

libusb-1.0.dll
libusb-1.0.dll.a

скопировал в Qt\5.7\mingw53_32\lib

libusb.h

в Qt\5.7\mingw53_32\include

в .pro

win32: LIBS += -llibusb-1.0

в проекте:

Код:

#include "libusb.h"

Код:

qDebug() << "*************" << libusb_init(NULL);

Ответ: ************* 0

Никаких ошибок нет.

Попробуйте пересобрать проект.

[flammmable]

Огромное спасибо, ув.PimenS. Всё заработало! Я сутки бился над этой проблемой. Понимаю, подключение библиотек - азы, но начинать - всегда непросто. Спасибо!
(спрашивал на crossplatform.ru, там - не_очень, дал ссылку на вас

[ssoft]

ИМХО, добавлять include и lib в Qt или MinGW некорректно.

Достаточно было правильно написать включение библиотеки в прект

Код:

win32: LIBS += -lC:\Qt\libusb-1.0.20\MinGW32\static\libusb-1.0

[PimenS]

ИМХО, добавлять include и lib в Qt или MinGW некорректно.

Стало интересно, в чем некорректность?

[Bepec]

В принципе это допускается. Папка Qt и mingw ничем не хуже каталога libusb И это удобно, когда часто пользуешься библиотекой.

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

В общем та же ситуация, что и с форматированием кода - каждый кодит как хочет

[ssoft]

Стало интересно, в чем некорректность?

Когда работаешь один - можно кодить как угодно, добавлять свой код или править исходники сторонних библиотек.
Если необходимо работать совместно, то лучше уж сформировать нормальный проект с подмодулями, как это обсуждалось здесь (http://www.prog.org.ru/index.php?topic=30171.msg222516#msg222516).

1. Добавление исходников может нарушать лицензии на использование других библиотек.
2. Инструмент разработки - это именно инструмент, одинаковый у всех. Изменение инструмента может повлечь проблемы бинарной несовместимости при распространении ПО.
3. Для распространения необходима инструкция или патч для внесения изменения в сторонние библиотеки. А может еще потребоваться и пересборка, что не всегда возможно.

В данном конкретном примере библиотека libusb статическая и без зависимостей. Что было бы, если бы были зависимости и библиотека была динамической, переносили бы все в MinGW?

[PimenS]

В данном конкретном примере библиотека libusb статическая и без зависимостей. Что было бы, если бы были зависимости и библиотека была динамической, переносили бы все в MinGW?

В данном конкретном примере библиотека как раз динамическая.
И каким образом расположение .h файла библиотеки и расположение самой библиотеки влияет на ее зависимости?

Какую-то чушь вы пишите. Какая разница куда я скопировал библиотеку и ее .h?
Скопировал в Qt-шные include и lib, не пишу лишнюю строчку в файле проекта. Скопировал в другое место, пишу дополнение в INCLUDEPATH.

[Bepec]

1) Каким образом добавление исходников меняет лицензию open source библиотеки?
2) Библиотека Qt как инструмент остаётся прежним и не меняется. (WTF что за претензия)
3) Логично, что нужна инструкция.
Нелогично, насчёт патчей. Какие патчи в готовую библиотеку.
Нелогично, насчёт пересборки. Open-source библиотеки в 99%  распространяются в виде исходников. Так что собирать придётся всё равно.

[ssoft]

В данном конкретном примере библиотека как раз динамическая.
И каким образом расположение .h файла библиотеки и расположение самой библиотеки влияет на ее зависимости?
Какую-то чушь вы пишите. Какая разница куда я скопировал библиотеку и ее .h?

Динамическая, статическая, какая разница?
На счет зависимостей не знаю, это ваши домыслы).
Куда вы скопировали библиотеку и заголовки локально на своем ПК мне тоже все-равно. А вот если бы это был совместный проект, то здесь разница есть.

Приведу пример.

Предположим у меня есть библиотека libA, которая зависит от libВ, libC. Для того, чтобы таким образом подключить библиотеку libA, нужно (для единообразия) также подключить и libB и libC. Предположим я работаю не над одним проектом, таких библиотек становится больше.
Если мне потребуется сменить инструмент разработки (версию компилятора, например) все эти библиотеки потребуется добавлять заново. Но это не самое плохое.
Если я работаю одновременно над несколькими проектами или ветками, который используют разные версии libA, libB или libC, что-то плохо представляю как в этом случае адекватно разрешать конфликты.
Если я работаю над проектом не один, то мне необходимо обязать других людей использовать такой же подход (проектные файлы являются частью проекта).

Нужны такие геморрои? Мне лично нет. В ваших проектах - выбор за вами).

Насчет патчей в библиотеку. Имеется в виду, что при распространении проекта необходимо будет убедить участников внести такие же правки в свой инструмент разработки. Что это, если не патч инструментария, пусть он даже не изменяет исходных текстов, а лишь меняет состав библиотек?

Про лицензирование. Open Source использует различные виды лицензий, например GNU (http://www.gnu.org/licenses/). Если вы собираетесь распространять свое ПО собранное с вашим особым составом исходников или изменением самих исходников, будьте добры опубликуйте их.

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

Существуют лицензии, вообще запрещающие любые изменения, например http://www.divx.com/en/divx-eula-ru.

[Bepec]

Все приведённые вами проблемы решаются передачей файлов проекта. Со структурой папок и проектом, в котором описаны пути.

А вот чтобы воссоздать такое без проекта, достаточно описать в руководстве libC зависимости от libA и libB. А уж какие пути к инклудам укажет программист - вот вообще без разницы
Суть в чём - без разницы где будут хранится исходники. Однотипные строки #include <liba.h> #include<libb.h> будут работать на любом компе, с любым местоположением исходников, как только путь к ним окажется в "include path".

Вот с разными версиями тут уже засада - тут каждый измудряется как может. Кто то имеет несколько десятков инклудов. У кого-то разруливается при помощи макросов. У третьих системы сборки работают.

[ssoft]

Все приведённые вами проблемы решаются передачей файлов проекта. Со структурой папок и проектом, в котором описаны пути.
...
Вот с разными версиями тут уже засада - тут каждый измудряется как может. Кто то имеет несколько десятков инклудов. У кого-то разруливается при помощи макросов. У третьих системы сборки работают.

Технически возможна любая реализация хранения исходников. Вопрос был - насколько целесообразно (корректно) смешивать разные исходники между собой?

Никто (надеюсь) ведь не смешивает исходники несколько совершенно разных библиотеки libA, libB, libC в одно месиво? Так в чем целесообразность смешения системных и библиотечных исходных кодов?

ИМХО, проект должен собираться "из коробки". Среды сборки могут быть разными - msvc, mingw, gcc и т.п. Для всех писать свою инструкцию? Почему бы сразу нормально не оформить проект, чтобы другие люди вспоминали только добрыми словами?

qmake, cmake, qbs - чем не системы сборки? Зачем еще придумывать макросы и др., тем более которые изменяют окружение инструмента разработки? Чтобы потом долго искать, что заголовок <math.h> на самом деле не стандартный, а из какой-нибудь SuperLib?

Возможно, для некоторых разработчиков - это удобно, но для тестировщиков или интеграторов, которые оперируют разными версиями ПО, - это просто невыносимо.

[Bepec]

Та плюньте. Не невыносимо. Видел и на дефайнах построенную систему. Вполне живо работает, ничего делать не надо. Если дефайнов нет, предупреждения и ошибки выдаёт корректные и понятные. А в ваших "многообразных" проектах черт ногу может сломать