Комментарии 13
Здорово все, конечно. Но когда малинка стала микроконтроллером? По-моему, это все таки процесор с перефирией
Я то вообще удивился, что нашлось хоть что-то, с учётом качества картинки. Да ещё и матрёшку признали антропоморфной (хотя по правде сказать, сеть была крайне неуверена и чаще предсказывала, что это «bottle»).
Если для кросскомпиляции нужно специфическое окружение — не проще ли chroot вместо docker'а?
Проблема в переносимости — такой подход не заинтегрировать гладко в CI, если нужно, посколько трюк с qemu сработает только тогда, когда на самой хостовой машине, выделенной под CI поставлен qemu-user-static. Поправьте меня, если не прав.
Непонятно, при чем тут qemu.
Я процесс кросс-компиляции представляю так:
Берём кросс-компилятор, который умеет целевую платформу. Делаем sysroot, точно как на целевой платформе. После make install получим набор файлов, который нужно перенести в вашу машинку. Можно завернуть в .deb, можно завернуть в образ sd карты через genext2fs… CI и qemu это уже совершенно другие задачи.
Извиняюсь, наверное стоило сразу попробовать показать примером то, что имелось ввиду. Да, можем взять нашу плату, выкачать оттуда заголовочные файлы с нативными библиотеками на хост и указывать кросс-компилятору в качестве зависимостей. Но это не совсем прозрачный подход. Никто не будет запоминать, в каком порядке и откуда на конечном устройстве появились нужные пакеты зависимостей. Для себя — нормально, но как только появляется новый пользователей этого процесса — для него это магия типа "не трогай эти папочки — сломаешь сборку".
То есть ещё раз — Ваше решение правильное, но хочется иметь воспроизводимый набор инструкций. Например, взять публичный чистый Raspbian образ, докачать в него зависимостей и использовать в качестве rootfs донора. Тогда если по шагам:
Качаем Raspbian Lite
wget http://downloads.raspberrypi.org/raspbian_lite/archive/2018-11-15-21:03/root.tar.xz
Распаковываем и внедряемся:
mkdir sysroot sudo tar -xf root.tar.xz -C sysroot sudo chroot sysroot
Только на chroot получим ошибку
chroot: failed to run command ‘/bin/bash’: Exec format errorПотому что OS то для ARM, да ещё и 32 битная, а мы (я в данном случае) работаем на 64-битном Intel® Core™ i5.
Тогда то и можно попробовать qemu:
sudo apt-get install -y qemu-user-static
sudo cp /usr/bin/qemu-arm-static sysroot/usr/bin/
sudo chroot sysroot Готово, я внутри и могу доустанавливать пакеты.
Как-то сложно. Я это вижу так. От каких пакетов зависит opencv известно? По-моему, да ;). Raspbian это же вариация debian? Значит, можно распаковать -dev пакеты, вместе с их зависимостями, именно тех версий, что используются в релизе вашего raspbian.
Все это вполне автоматизируется. Магии apt должно хватить.
Может на основе этого сделаете готовый Jenkins-agent и выложите на hub.docker.com? Это поможет не строить велосипеды и за минуты готовить среду для сборки opencv проекты
Вопрос насколько долго это будет актуально и гибко. Выложить может любой пользователь, но поддерживать будет не каждый. Чего далеко ходить, python-opencv: Maintainer Kubuntu Developers, не OpenCV team.
У малинки вроде бы не плохая видеокарта 24gflops (3-яя модель уже 93gflops) в теории раз в 30 быстрее cpu.
гугл даже выдает открытые реализации opencl, т.е. в теории это решаемо.
Здорово, собирал сам 3.4.1 для Raspbian Jessie как раз из-за dnn. Недавно задумался переходить на Стретч, и тут ваша статья. А собранный deb можно где-нибудь стянуть?
Ночью спит спокойно мама — мы собираем OpenCV для Raspbian'a