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

Добрый день!

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

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

Добрый день.

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

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

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

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

Получилось собрать. Правда по ходу дела возникли дополнительные проблемы, которые пришлось решать:
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.

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

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

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

Добрый день, Алексей!
Нет не собирается. Вчера кое-что пропустил:
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). Я использовал такой вариант вчера - прокатывало.

Вообще можете развернуть МСВС на виртуалке. В торентах видел образ.
Правда, чтоб собрать 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. Судя по версиям установленных пакетов, мне достался самый первый выпуск.

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

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

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

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

Добрый день, Алексей!
Собрался сделать вам пул реквест со своим вариантом, но вовремя увидел ваши последние комиты. Протестировал.
Все собралось. Даже похоже, что проверка версии компилятора нормально отрабатывает, хотя у меня версия 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)

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

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

Попытался скомпилировать тест из каталога 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

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

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

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

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

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

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

Да, если не указать флаг линкеру -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?

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

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

Без 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 только при срабатывании условий.

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

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

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

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

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