Для разработки под wb5 у меня на виртуалке сейчас стоит gcc 4.6.3
Можно ли использовать поновее и если да, то как обновиться и надо ли что то добавлять на сами контроллеры ?
Доброго времени,
По идее, вы можете просто установить кросс-компилятор нужной версии (для debian/ubuntu - пакет gcc-arm-linux-gnueabi, в debian testing доступна версия 7.2.0) на компьютер, который собираетесь использовать для сборки. На контроллере ничего дополнительного не требуется.
А под виртуалкой никак не получится ?
Сейчас я использую qemu + chroot_this.sh из скачанного образа rootfs…
Просто у меня под виртуалкой собраны “тяжелые” сторонние библиотеки (snmp++, agent++, boost::asio, boost::regex, openssl, mosquitto) и я пока не оч представляю, получится ли их поднять кросс-компилятором
Для справки, у нас есть Docker-образ для разработки, в котором уже развёрнут Debian с qemu и всем необходимым для сборки софта в окружении контроллера. По сути, выполняет то же самое, что ваша связка. Посмотреть можно на https://github.com/contactless/wirenboard.
В вашем случае можно попробовать взять gcc из более новых версий Debian, для этого надо дописать в настройки APT:
/etc/apt/sources.list.d/stretch.list:
deb http://mirror.yandex.ru/debian stretch main
/etc/apt/preferences.d/stretch:
Package: *
Pin: release a=stretch
Pin-Priority: 1
после чего делаем
$ apt-get update
$ apt-get -t stretch install gcc
Стоит проверить это на изолированном окружении, так как может поломать какие-то пакеты.
Попробовал, начал ставить gcc -написал версия gnu libc требует kernel 3.2 или выше…
Это у меня старый rootfs или это ядро в wb5 не поддерживается?
Если поддерживается-где взять rootfs поновее?
Так) концепция изменилась
нашел у вас в github.com/contactless/wirenboard/releases чуть новее rootfs от 18.6.2014
Одел на него -как вы написали выше- gcc и все дела, все получилось, gcc встала 6.3.0
Собрал простой свой бинарник, все ок
Под виртуалкой qemu он запустился
А запустил на контроллере wb5 - все плохо(
root@wbAZV5TSFJ:/opt/tst# ./shmbuf_rpl_t
./shmbuf_rpl_t: /usr/lib/arm-linux-gnueabi/libstdc++.so.6: version GLIBCXX_3.4.20' not found (required by ./shmbuf_rpl_t) ./shmbuf_rpl_t: /usr/lib/arm-linux-gnueabi/libstdc++.so.6: versionGLIBCXX_3.4.21’ not found (required by ./shmbuf_rpl_t)
Какую тогда версию gcc/g++ можно поставить ? Чтоб работало на wb5 ? И как это сделать, указать apt-get-у gcc<версия> ?
ну собственно на контроллер вам нужно libstdc++ тоже поставить новее, из stretch.
А gcc-4.7 вас не устраивает? У нас всё собирается им.
собрал в --static -запустилось, но бинарник естественно распух, но это самое простое приложение, не знаю, правильно ли будет все собирать статиком и не вылезет ли еще чего неприятного…
про gcc 4.7 - у меня почему то стоял gcc 4.6.3, а нужен был ключик -std=c++11
Советуете поставить 4.7 ? Убрать stretch и поставить apt-get install gcc4.7 ?
и еще почему стал смотреть версии постарше- в gcc4.6.3 у std::list::size() сложность O(n) , а хотелось бы O(1), в более поздних вроде как пофиксили
Сейчас попробовал - взял “пустой” rootfs, без stretch,
apt-get install gcc -поставился опять 4.6.3
как поставить 4.7…? И какая самая старшая версия подойдет для текущих прошивок wb5 ?
Я бы не советовал собирать что-либо со --static. Приложение может перестать нормально работать в довольно неожиданных местах, не говоря уже о лицензионных тонкостях. Glibc не предназначена для статической линковки. Вот тут можно почитать поподробнее.
Now you might be thinking, hey what about statically linking (E)GLIBC? Let me warn you that doing so is a bad idea. Some features in (E)GLIBC will only work if the statically linked (E)GLIBC is the exact same version of (E)GLIBC installed on the system, making statically linking pointless, if not downright problematic. (E)GLIBC’s libdl is quite notable in this regard, as well as several networking functions. (E)GLIBC is also licensed under LGPL. Which essentially means that if you give out the source to your application, then in most cases you can distribute statically linked binaries with it, but otherwise, not. Also, since 99% of the functions are marked as requiring extremely old versions of (E)GLIBC, statically linking is hardly necessary in most cases.
В вашем случае, возможно, прокатит -static-libstdc++ (сообщение об ошибке говорит про C++: ... GLIBCXX_3.4.21 not found), а также на всякий случай -static-libgcc. Лицензии libstdc++ и libgcc позволяют делать так, не раскрывая своих исходников.
В общем же случае можно попробовать установить свежий компилятор в окружение старой Glibc, но это разумеется не решит вашего вопроса касательно старой реализации std::list. Да и не стоит того, если у вас есть полный контроль над железкой.
Ещё раз, сейчас мы весь свой софт собираем gcc-4.7.
Исходники для сборки нашего сборочного контейнера тут: https://github.com/contactless/wirenboard/tree/master/devenv
P.S. Я, честно говоря, так и не понял, чем вам не подошёл наш docker devenv, где всё работает из коробки.
У меня есть настроенный rootfs с gcc4.6.3,обходился им до сиз пор. docker devenv я не пробовал,потому как не понял, можно ли под ним поднять все, что мне нужно -я писал выше- boost, snmp++,agent++ и тд