Russian Qt Forum
Ноябрь 24, 2024, 17:47 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
 
  Начало   Форум  WIKI (Вики)FAQ Помощь Поиск Войти Регистрация  

Russian Qt Forum > Forum > Qt > Вопросы новичков > Подключение libusb-1.0 к Qt (MinGW) в Windows 8
Страниц: [1]   Вниз
« предыдущая тема следующая тема »
  Печать  
Автор Тема: Подключение libusb-1.0 к Qt (MinGW) в Windows 8  (Прочитано 11474 раз)
flammmable
Гость
« : Июнь 22, 2016, 10:11 »
Добрый день!
Пытаюсь соединить устройство (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'

Что я делаю не так?
« Последнее редактирование: Июнь 22, 2016, 11:11 от flammmable » Записан
PimenS
Крякер
****
Offline Offline

Сообщений: 371


Просмотр профиля
« Ответ #1 : Июнь 22, 2016, 12:28 »
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
Гость
« Ответ #2 : Июнь 22, 2016, 13:19 »
Огромное спасибо, ув.PimenS. Всё заработало! Я сутки бился над этой проблемой. Понимаю, подключение библиотек - азы, но начинать - всегда непросто. Спасибо!
(спрашивал на crossplatform.ru, там - не_очень, дал ссылку на вас Подмигивающий
« Последнее редактирование: Июнь 22, 2016, 13:29 от flammmable » Записан
ssoft
Программист
*****
Offline Offline

Сообщений: 584


Просмотр профиля
« Ответ #3 : Июнь 22, 2016, 15:21 »
ИМХО, добавлять include и lib в Qt или MinGW некорректно.

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

Код:
win32: LIBS += -lC:\Qt\libusb-1.0.20\MinGW32\static\libusb-1.0
Записан
PimenS
Крякер
****
Offline Offline

Сообщений: 371


Просмотр профиля
« Ответ #4 : Июнь 22, 2016, 16:41 »
Цитата: ssoft от Июнь 22, 2016,  15:21
ИМХО, добавлять include и lib в Qt или MinGW некорректно.

Стало интересно, в чем некорректность?
Записан
Bepec
Гость
« Ответ #5 : Июнь 22, 2016, 18:42 »
В принципе это допускается. Папка Qt и mingw ничем не хуже каталога libusb Улыбающийся И это удобно, когда часто пользуешься библиотекой.

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

В общем та же ситуация, что и с форматированием кода - каждый кодит как хочет Веселый
Записан
ssoft
Программист
*****
Offline Offline

Сообщений: 584


Просмотр профиля
« Ответ #6 : Июнь 23, 2016, 08:56 »
Цитата: PimenS от Июнь 22, 2016,  16:41
Стало интересно, в чем некорректность?

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

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

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

Сообщений: 371


Просмотр профиля
« Ответ #7 : Июнь 23, 2016, 09:16 »
Цитата: ssoft от Июнь 23, 2016,  08:56
В данном конкретном примере библиотека libusb статическая и без зависимостей. Что было бы, если бы были зависимости и библиотека была динамической, переносили бы все в MinGW?

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

Какую-то чушь вы пишите. Какая разница куда я скопировал библиотеку и ее .h?
Скопировал в Qt-шные include и lib, не пишу лишнюю строчку в файле проекта. Скопировал в другое место, пишу дополнение в INCLUDEPATH.
Записан
Bepec
Гость
« Ответ #8 : Июнь 23, 2016, 13:45 »
1) Каким образом добавление исходников меняет лицензию open source библиотеки?
2) Библиотека Qt как инструмент остаётся прежним и не меняется. (WTF что за претензия)
3) Логично, что нужна инструкция.
Нелогично, насчёт патчей. Какие патчи в готовую библиотеку.
Нелогично, насчёт пересборки. Open-source библиотеки в 99%  распространяются в виде исходников. Так что собирать придётся всё равно.
Записан
ssoft
Программист
*****
Offline Offline

Сообщений: 584


Просмотр профиля
« Ответ #9 : Июнь 23, 2016, 18:03 »
Цитата: PimenS от Июнь 23, 2016,  09:16
В данном конкретном примере библиотека как раз динамическая.
И каким образом расположение .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
Гость
« Ответ #10 : Июнь 24, 2016, 03:09 »
Все приведённые вами проблемы решаются передачей файлов проекта. Со структурой папок и проектом, в котором описаны пути.

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

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

Сообщений: 584


Просмотр профиля
« Ответ #11 : Июнь 24, 2016, 08:05 »
Цитата: Bepec от Июнь 24, 2016,  03:09
Все приведённые вами проблемы решаются передачей файлов проекта. Со структурой папок и проектом, в котором описаны пути.
...
Вот с разными версиями тут уже засада - тут каждый измудряется как может. Кто то имеет несколько десятков инклудов. У кого-то разруливается при помощи макросов. У третьих системы сборки работают.

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

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

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

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

Возможно, для некоторых разработчиков - это удобно, но для тестировщиков или интеграторов, которые оперируют разными версиями ПО, - это просто невыносимо.
Записан
Bepec
Гость
« Ответ #12 : Июнь 24, 2016, 12:50 »
Та плюньте. Не невыносимо. Видел и на дефайнах построенную систему. Вполне живо работает, ничего делать не надо. Если дефайнов нет, предупреждения и ошибки выдаёт корректные и понятные. А в ваших "многообразных" проектах черт ногу может сломать Веселый
Записан
Страниц: [1]   Вверх
  Печать  
« предыдущая тема следующая тема »
 
Перейти в:  


Страница сгенерирована за 0.061 секунд. Запросов: 22.