Форум: Техническая поддержка

Тема: Возможно ли собрать x502api без libusb?

Вы не вошли.

 Поиск | Регистрация | Вход 

06.11.2019 14:41:37
#1

Участник
Откуда: Мурманск
Здесь с 24.11.2018
Сообщений: 20

Возможно ли собрать x502api без libusb?

Добрый день!

Хотим использовать E502 с подключением по Ethernet к МСВС 3.0 с ядром 2.4.32.
libusb 1.0 там, похоже, собрать не возможно.
Т.к. функционал работы с АЦП по USB не нужен, то и возникла мысль каким-то образом этот функционал убрать из сборки.
Но судя по CMakeList.txt libusb сейчас является обязательной для сборки.

Есть ли какое-то решение такой задачи без допиливания исходников x502api?

06.11.2019 18:24:13
#2

Сотрудник "Л Кард"
Здесь с 17.04.2014
Сообщений: 885

Re: Возможно ли собрать x502api без libusb?

Добрый день.

В принципе сделать в CMakeList.txt сборку usb опциональной не сложно, попробую изменить в ближайшее время. А cmake там собрался?

06.11.2019 19:23:10
#3

Сотрудник "Л Кард"
Здесь с 17.04.2014
Сообщений: 885

Re: Возможно ли собрать x502api без libusb?

В репозиторий выложил изменения для x502api, можете скачать через mercurial (hg).
Вам нужно будет собрать соответственно с отключенными опциями:
X502API_ENABLE_DEV_L502   OFF
E502API_ENABLE_USB            OFF
E502API_ENABLE_DNSSD       OFF (если там нет avahi и не нужен автоматический поиск устройств в сети)

Соберется ли и будет ли работать на МСВС не могу сказать, так как понятно не на чем попробовать.
В любом случае тогда сообщите о результатах.

06.11.2019 19:51:03
#4

Участник
Откуда: Мурманск
Здесь с 24.11.2018
Сообщений: 20

Re: Возможно ли собрать x502api без libusb?

Большое спасибо!
cmake 2.6.4 собрался. Версии выше уже не собираются.
Завтра буду пробовать, отпишусь по результатам.
Правда у меня сейчас то же не на чем тестировать, но скоро появится аппарат.

07.11.2019 17:58:24
#5

Участник
Откуда: Мурманск
Здесь с 24.11.2018
Сообщений: 20

Re: Возможно ли собрать x502api без libusb?

Получилось собрать. Правда по ходу дела возникли дополнительные проблемы, которые пришлось решать:
1.В ядре 2.4.32 нет функции clock_gettime(). Используется в lib/ltimer и lib/osspec. Заменил на использование gettimeofday(), если clock_gettime() отсутствует.
2.struct timeval объявлена не в <time.h>, а в <sys/time.h>, который надо подключать отдельно.
3.Похоже что gcc 2.95.4 воспринимает переменные объявленные только в начале блоков. Подобная ошибка возникла в единственном месте - в функции src/x502api_config.c->X502_CalcOutFreq() с переменной freq_div.

Нужно еще собрать пример, чтоб было чем проверить работоспособность.

07.11.2019 18:16:44
#6

Сотрудник "Л Кард"
Здесь с 17.04.2014
Сообщений: 885

Re: Возможно ли собрать x502api без libusb?

А первый пункт Вы сделали именно в общем виде проверкой существования функции? через cmake?

07.11.2019 19:18:07
#7

Сотрудник "Л Кард"
Здесь с 17.04.2014
Сообщений: 885

Re: Возможно ли собрать x502api без libusb?

Обновленная сейчас версия x502 собирается без изменений?

08.11.2019 14:09:37
#8

Участник
Откуда: Мурманск
Здесь с 24.11.2018
Сообщений: 20

Re: Возможно ли собрать x502api без libusb?

Добрый день, Алексей!
Нет не собирается. Вчера кое-что пропустил:
1. Убрал несколько опций компилятора:

-Werror=implicit-int
-Werror=implicit-function-declaration
-Werror=strict-prototypes
-Werror=return-type
-Wextra
-Winit-self
-Wstrict-aliasing
-Wfloat-equal
-Wunsafe-loop-optimizations
-Wlogical-op
-Wno-unused-parameter
-Wno-unused-variable
-fvisibility=hidden

-W  из CMakeLists.txt, -f - из x502libs.cmake, а так же изменил макрос X502_EXPORT в src/x502api.h, т.к. атрибут visibility так же не поддерживается этой версией компилятора.
2.src/x502api_config.c (302) X502_CalcDinFreq() - перенос объявления freq_div в начало блока.
3.clock_gettime() используется еще в lib/osspec/osspec.c.
Кроме того ltimer то же не собирается. Почему-то check_function_exists() в ltimer.cmake не отрабатывает как надо и в итоге все равно пытается собраться ветка с clock_gettime() в lib/ltimer/ports/linux/lclock.c.
check_library_exists(rt clock_gettime "" HAVE_LIBRT) делает то же, что и check_function_exists(clock_gettime HAVE_CLOCKGETTIME). Я использовал такой вариант вчера - прокатывало.

08.11.2019 15:43:35
#9

Участник
Откуда: Мурманск
Здесь с 24.11.2018
Сообщений: 20

Re: Возможно ли собрать x502api без libusb?

Вообще можете развернуть МСВС на виртуалке. В торентах видел образ.
Правда, чтоб собрать cmake пришлось обновить autoconf до версии 2.68, automake до версии 1.11.6, m4 до версии 1.4.11, libtool до версии 2.4.2. После этого я смог собрать cmake 2.6.4. Все собирал из исходников.
ssh там поднят из коробки.

Сложность еще в том, что МСВС 3.0 было несколько выпусков. Отличаются версиями установленных пакетов. Во всех выпусках ядро 2.4.32. Судя по версиям установленных пакетов, мне достался самый первый выпуск.

08.11.2019 15:50:57
#10

Участник
Откуда: Мурманск
Здесь с 24.11.2018
Сообщений: 20

Re: Возможно ли собрать x502api без libusb?

Почему-то check_function_exists() в ltimer.cmake не отрабатывает как надо и в итоге все равно пытается собраться ветка с clock_gettime() в lib/ltimer/ports/linux/lclock.c.

Ошибся. check_function_exists() нормально отрабатывает. Просто LTIMER_DEFINITIONS надо еще добавить к сборке x502lib.

08.11.2019 16:09:45
#11

Участник
Откуда: Мурманск
Здесь с 24.11.2018
Сообщений: 20

Re: Возможно ли собрать x502api без libusb?

И еще последний момент:
В devs/e502/e502api_tcp.c (39) - нет файла asm-generic/ioctls.h.

08.11.2019 17:50:46
#12

Сотрудник "Л Кард"
Здесь с 17.04.2014
Сообщений: 885

Re: Возможно ли собрать x502api без libusb?

А pthread_mutex_timedlock при этом принимает struct timespec? т.е. определение структуры есть несмотря на отсутствие clock_gettime?

09.11.2019 15:00:57
#13

Участник
Откуда: Мурманск
Здесь с 24.11.2018
Сообщений: 20

Re: Возможно ли собрать x502api без libusb?

timespec объявлена в time.h, timeval - в sys/time.h (точнее структура определяется в bits/time.h, но этот файл включается в sys/time.h).

13.11.2019 13:09:16
#14

Участник
Откуда: Мурманск
Здесь с 24.11.2018
Сообщений: 20

Re: Возможно ли собрать x502api без libusb?

Добрый день, Алексей!
Собрался сделать вам пул реквест со своим вариантом, но вовремя увидел ваши последние комиты. Протестировал.
Все собралось. Даже похоже, что проверка версии компилятора нормально отрабатывает, хотя у меня версия cmake 2.6.4.

Еще несколько пожеланий, если можно:
1. В переменной ${COMPILE_DEFINITIONS} начинают дублироваться значения в подпроектах e502 и l502 из-за присваивания

set(COMPILE_DEFINITIONS ${COMPILE_DEFINITIONS} ${LTIMER_DEFINITIONS})

Если исправить на

set(COMPILE_DEFINITIONS ${LTIMER_DEFINITIONS})

дублирования не будет. Но исчезнет возможность передавать в подпроекты дополнительные параметры компиляции. Хотя эта возможность сейчас и не используется, на сколько я понял.

2.В МСВС используется кодировка консоли КОИ8-Р, мне пришлось перекодировать исходники, чтоб можно было нормально читать комментарии. Столкнулся с тем, что в двух случаях перекодирование завершается с ошибкой из-за подобных открывающих/закрывающих кавычек:

“ИЛИ”

Это встречается в двух файлах:

  • src/x502api.h строка 356, 2069
    devs/l502/l502api_compat.h строка 228

После того как я заменил эти кавычки на обычные перекодировка прошла без ошибок.

3.Можно не привязываться к конкретной версии компилятора, а использовать проверку поддержки опций. Я написал такую конструкцию:

#для GCC устанавливаем повышенный уроень предупреждения компилятора
if(CMAKE_COMPILER_IS_GNUCC)
    set(WARNOPTS
        -Wall -Wformat-security -Wundef -Wshadow -Wpointer-arith -Wcast-align
        -Wwrite-strings  -Wsign-compare -Waggregate-return -Winline -Wno-aggregate-return)
    include(CheckCCompilerFlag)
    set(CHECK_FLAGS
        -Werror=implicit-int -Werror=implicit-function-declaration -Werror=strict-prototypes -Werror=return-type
        -Wextra -Winit-self -Wstrict-aliasing -Wfloat-equal
        -Wunsafe-loop-optimizations -Wlogical-op
        -Wno-unused-parameter -Wno-unused-variable)
    foreach(CUR_FLAG ${CHECK_FLAGS})
        CHECK_C_COMPILER_FLAG(${CUR_FLAG} FLAG_ENABLE)
        if(FLAG_ENABLE)
            set(WARNOPTS ${WARNOPTS} ${CUR_FLAG})
        endif()
        unset(FLAG_ENABLE)
    endforeach(CUR_FLAG)
    add_definitions(${WARNOPTS})
endif(CMAKE_COMPILER_IS_GNUCC)

Такой же подход можно использовать и для -fvisibility:

    CHECK_C_COMPILER_FLAG(-fvisibility=hidden FLAG_ENABLE)
    if(FLAG_ENABLE)
        set_target_properties(${PROJECT_NAME} PROPERTIES COMPILE_FLAGS "-fvisibility=hidden")
    endif(FLAG_ENABLE)
    unset(FLAG_ENABLE)
13.11.2019 13:25:02
#15

Участник
Откуда: Мурманск
Здесь с 24.11.2018
Сообщений: 20

Re: Возможно ли собрать x502api без libusb?

Еще добавлю. Перед компиляцией я заменяю виндовый перевод строки в исходниках на Unixовый. В нескольких файлах исходных кодов используется виндовый вариант и сборка завершается ошибкой. Видимо этот древний gcc не понимает CRLF.

13.11.2019 14:30:22
#16

Сотрудник "Л Кард"
Здесь с 17.04.2014
Сообщений: 885

Re: Возможно ли собрать x502api без libusb?

Спасибо.
Как будет возможность (думаю к концу недели), включу Ваши предложения. 3 пункт конечно лучше сделать с явной проверкой как у Вас. По первому, думаю  сбрасывать переменную в начале проекта каждой библиотеки (чтобы если в самом проекте библиотеки добавится в будущем в других местах работа с COMPILE_DEFINITIONS последующая строка их не отменила). Передача извне не используется, а если понадобится в будущем, то наверное правильнее будет сделать отдельной переменной для внешних определений, которая внутри проекта не изменяется.

13.11.2019 16:58:30
#17

Участник
Откуда: Мурманск
Здесь с 24.11.2018
Сообщений: 20

Re: Возможно ли собрать x502api без libusb?

Алексей L Card пишет:

А pthread_mutex_timedlock при этом принимает struct timespec? т.е. определение структуры есть несмотря на отсутствие clock_gettime?

Попытался скомпилировать тест из каталога tests/x502_rdy_cntr_tst. Выяснилось, что в

glibc

нет функций:

pthread_mutex_timedlock

и

pthread_timedjoin_np

.

pthread_mutex_timedlock

начинается только с версии 2.1.91

pthread_timedjoin_np

- 2.4
Они используются в lib/osspec/osspec.c
Интересно, что при сборке библиотек это никак не обнаруживается, видимо потому что нет линковки с libpthread.

Для обхода

pthread_timedjoin_np

можно использовать макрос

OSSPEC_THREAD_NO_TIMEOUT

, а вот для

pthread_mutex_timedlock

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

13.11.2019 19:43:49
#18

Сотрудник "Л Кард"
Здесь с 17.04.2014
Сообщений: 885

Re: Возможно ли собрать x502api без libusb?

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

А -lpthread пришлось при сборке программы указывать?

Правда по идее эти функции не должны быть объявлены и в заголовках, и gcc должен на это выдавать хотя бы предупреждения (а при нужных флагах ошибку), но возможно в Вашей версии gcc еще этого нет.

В принципе для mutex'а можно использовать pthread_mutex_lock (тоже ввести макрос), там при корректной работе нигде этот таймаут не должен использоваться, только на случай ошибки в библиотеке.

а pthread_cond_timedwait при этом тоже нет (правда event используется только в usb, т.к. мы его отключили он не используется, поэтому если даже этой функции нет, то ошибки на него не будет)

13.11.2019 20:49:00
#19

Сотрудник "Л Кард"
Здесь с 17.04.2014
Сообщений: 885

Re: Возможно ли собрать x502api без libusb?

Да, если не указать флаг линкеру -Wl,--no-undefined, то библиотеки могут собираться с неопределенными символами (в ответе тут например https://stackoverflow.com/questions/418 … -redundant описано зачем это сделано). Думаю добавить его при сборке библиотеки, чтобы выдавались ошибки уже при сборке библиотеки (этот флаг есть в Вашей версии gcc/ld?)

Вообще потоки и события используются именно в коде usb, при этом так как libusb уже линкуется с libpthread, то не было ошибок при сборке приложения со штатной библиотекой без явной линковки с libpthread. 

В остальной части используются только mutex-ы, чтобы приложение могло вызывать функции из разных потоков. При этом явная линковка с libpthread, если приложение не использует потоки, не должна требоваться, т.к. эти символы для mutex дублированы и в glibc и если приложение не будет использовать потоки и явно использовать libpthread, то должны использоваться пустые заглушки из glibc (например тут обсуждается https://stackoverflow.com/questions/111 … -same-apis, включая комментарий Zan Lynx).

Можете проверить - если добавить флаг линкера -Wl,--no-undefined (через свойство LINK_FLAGS цели библиотеки), выдаст ли сборка библиотеки ошибки о недостающих символах?
Если убрать OSSPEC_USE_EVENTS и OSSPEC_USE_THREADS в osspec_cfg.h и в osspec_mutex_lock использовать всегда pthread_mutex_lock, соберется ли библиотека и приложение даже без использования -lptheread?

14.11.2019 10:57:02
#20

Участник
Откуда: Мурманск
Здесь с 24.11.2018
Сообщений: 20

Re: Возможно ли собрать x502api без libusb?

Алексей L Card пишет:

А -lpthread пришлось при сборке программы указывать?

Да, пришлось указывать. Похоже, что в libusb явно указана линковка с pthread, поэтому pthread будет подключен в любом случае. А если libusb нет, то появляется undefined reference.

Алексей L Card пишет:

эти функции не должны быть объявлены и в заголовках, и gcc должен на это выдавать хотя бы предупреждения (а при нужных флагах ошибку), но возможно в Вашей версии gcc еще этого нет.

Да, этого флага нет. Это -Werror=implicit-function-declaration, который мы уже убрали. Его нет и в варианте предупреждения: -Wimplicit-function-declaration, что сейчас выглядит довольно странно, т.к. кажется что это базовая проверка. Но видимо 20 лет назад на этот счет было другое мнение.

Алексей L Card пишет:

соберется ли библиотека и приложение даже без использования -lptheread?

Без libusb видимо не соберется, т.к. все равно остаются еще мьтексы из нее.
Сегодня продолжу эксперименты.

Вообще планировал с помощью check_library_exists() проверять наличие pthread_mutex_timedlock и pthread_timedjoin_np и выставлять соответствующие дефайны.
Учитывая, что pthread_timedjoin_np используется только в ветке с USB, то OSSPEC_USE_THREADS можно выставлять просто при выключенной поддержке USB.
Похоже надо osspec_cfg.h преобразовать в файл конфигурации с настраиваемыми параметрами, или вообще OSSPEC_USE_EVENTS и OSSPEC_USE_THREADS оттуда убрать и задавать в cmake при срабатывании условий. Я бы даже предложил эти макросы сделать обратными типа NO_OSSPEC_USE_EVENTS и NO_OSSPEC_USE_THREADS по аналогии с NO_CLOCKGETTIME. Причем в x502api эти макросы можно включать всегда, а в e502api только при срабатывании условий.

14.11.2019 11:22:19
#21

Участник
Откуда: Мурманск
Здесь с 24.11.2018
Сообщений: 20

Re: Возможно ли собрать x502api без libusb?

Флаг -Wl,--no-undefined похоже есть. По крайней мере CHECK_C_COMPILER_FLAG() его находит.

14.11.2019 11:38:01
#22

Участник
Откуда: Мурманск
Здесь с 24.11.2018
Сообщений: 20

Re: Возможно ли собрать x502api без libusb?

Если добавлять флаг -Wl,--no-undefined к сборке, то, видимо, нужно и libpthread подключать к библиотекам, иначе ошибка будет всегда.

14.11.2019 11:54:34
#23

Сотрудник "Л Кард"
Здесь с 17.04.2014
Сообщений: 885

Re: Возможно ли собрать x502api без libusb?

А на какие функции ругается при сборке с -Wl,--no-undefined без libpthread?

14.11.2019 13:05:29
#24

Участник
Откуда: Мурманск
Здесь с 24.11.2018
Сообщений: 20

Re: Возможно ли собрать x502api без libusb?

Осталась только pthread_mutex_timedlock().
Отключил OSSPEC_USE_THREADS и OSSPEC_USE_EVENTS.
Кстати, заметил что предупреждение об implicit declaration при сборке есть. Вчера я его не увидел, видимо.

14.11.2019 15:05:02
#25

Сотрудник "Л Кард"
Здесь с 17.04.2014
Сообщений: 885

Re: Возможно ли собрать x502api без libusb?

Если его заменить на обычный pthread_mutex_lock, то соберется нормально и без libpthread?

Контакты

Адрес: 117105, Москва, Варшавское шоссе, д. 5, корп. 4, стр. 2

Многоканальный телефон:
+7 (495) 785-95-25
Факс: +7 (495) 785-95-14

Отдел продаж: sale@lcard.ru
Техническая поддержка: support@lcard.ru

Время работы: с 9-00 до 19-00 мск

L-CARD в проектах