Подскажите про кросс-компиляцию в ARM

Вы забыли задать вопрос.

Случайно нажал отправить. Дайте 5 минут )

arm-none
что из этого мне нужно, чтобы успешно скомпилировать свой код (зависящий от пары so-файлов из дистрибутива)

я просто мимокрокодил, но что-то мне подсказывает, что ничего из этого. ищи arm-linux-...

чтобы успешно скомпилировать свой код (зависящий от пары so-файлов из дистрибутива)

Скачать сорцы этих so, кросс-компильнуть под ARM (желательно статическую либу *.a сделать).

Кросс-компильнуть сорцы своего приложения по ARM.

Всё.

Тебе, скорее всего, нужен компилятор не под Bare-metal, а под Linux. Ты про железо не уточнил. То бишь ставить тебе нужно не arm-none-eabi-{gcc,g++}, а arm-linux-gnueabi-{gcc, g++}.

Нету в стандартной поставке. Как сложно-то всё. С qemu ничего не выходит. С кросс-компиляцией тоже. В интернете толком ничего нет, словно никто и не озадачивался этим вопросом никогда)

С qemu ничего не выходит

С qemu ничего не выходит? Это же просто до безобразия, по крайней мере в debian. Настраиваешь qemu-binfmt, bootstrap, chroot и собирай сколько душе угодно.

В интернете толком ничего нет, словно никто и не озадачивался этим вопросом никогда)

Ай не заливай.

Видать нет arm-linux-* в стандартной поставке. Железо - raspberry

Видать нет arm-linux-* в стандартной поставке.

Значит бери в правую руку http://crosstool-ng.org/ в левую свободное время, и компилируй arm-linux-*

Железо - rasbberry

Полуркай raspberry pi toolchain, не может быть, чтобы его не было и пришлось собирать самому.

погодь, есть же в AUR. а если качать — так уж собранное.

Вот что-то:

https://github.com/raspberrypi/tools/

http://www.openframeworks.cc/setup/raspberrypi/Raspberry-Pi-Cross-compiling-g...

https://www.raspberrypi.org/forums/viewtopic.php?f=33&t=52957

Советуют ставить тулчейн от Linaro. Но я не знаю, насколько этот совет актуален, не владелец RPI.

Зато вон что в AUR есть.

aur/arm-bcm2708-linux-gnueabi 14.9c3d7b6-1 (3)
    GCC Cross Compiler Toolchain provided by RaspberryPi

Значит ТС как-то плохо искал, я бы удивился, если бы arm-linux-* не было, а arm-none-* был.

Правильно я понимаю, qemu используется в user mode, arm-програмы запускаются на x86-ядре, в arm-chroot-окружении, просто системные вызовы транслируются из arm в x86?

да.

Я посмотрел в пакетах - вроде есть. Дальше не стал искать. Оказалось не то. Спасибо. Буду дальше курить

И это реально работает? Ну там всякие веб-сервера и системные утилиты?

Так там arm-none-* в community, а arm-linux-* в AUR только. Хотя как я понимаю, от AUR до community один шаг.

На тебе мой скриптик для чрута в qemu (под raspberry):

#!/bin/bash
CHRT="ROOT"
if [ $# != 1 ]; then
    echo "usage: $0 image"
    exit 1
fi

function mnt(){
    mount -o bind $1 ${CHRT}$1
}
[ -f /proc/sys/fs/binfmt_misc/arm ] || echo ':arm:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x28\x00:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\x
ff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:/usr/bin/qemu-arm-static:' > /proc/sys/fs/binfmt_misc/register
mount -o loop,offset=62914560 $1 ${CHRT}
mnt /dev
mnt /dev/pts
mnt /sys
mount -t proc none ${CHRT}/proc
mnt /run
chroot ${CHRT}

А вот еще под кубитрак, если понадобится вдруг:

#!/bin/bash
function mnt(){
    mount --rbind $1 m$1
}

mount -o loop,offset=105906176 gentoo_8GB.img m
mount -t proc none m/proc
mount -o bind portage m/usr/portage
mnt /dev
mnt /sys
mnt /run
chroot m

Пы.Сы. Выкинь рач. Для разработки (да и просто для десктопа) лучше генту поставить.

А почему ты тыбрал путь эмуляции вместо кросскомпиляции? У меня просто сейчас такая дилема)

Люблю новые версии и systemd, ничего тут не поделаешь )

А почему ты тыбрал путь эмуляции вместо кросскомпиляции?

Потому что у меня на малинке дебилиан стоит, а на куби гента. Как ты предлагаешь обновлять дистр кросс-компиляцией? Не выйдет ничего!

Люблю новые версии и systemd

Убил бы! Самым извращенным способом. Скажем, заставил бы сожрать поцтеринга вместе с говном и костями...

Да, а откуда вдруг сомнения?

Просто в голове не укладывается) Это получается можно скачать фирмварь с какого-нибудь левого китайского девайса и запускать екзешники из него на своей машине?

Ты обновляешь img-образ малинки с помощью qemu и chroot, а потом заливаешь этот образ на флешку?

«пожалуйста, можно, но толко зачем?»

к тому же, что за бинарники, гвоздями прибитые к левому китайскому железу? что там может быть вообще интересного?

Сколько не лазил по китайским девайсам - всюду линукс, плюс бинарь, выполняющий основную функцию девайса. Зачем? Не знаю. Еще не придумал )

Можно чрутиться в QEMU, а можно собрать тулчейн от местного пользователя - https://www.linux.org.ru/forum/development/5519881.
Тулчейн этот я пробовал и сам - всё отлично работает на ARM

Можно еще пару вопросов уважаемым форумчанам?)

Получается, если у меня малина и кубиборда (arm6 и arm7), мне нужно собрать два тулчейна?

А все-таки, что насчет clang-а? Он же умеет изкоробки тенерить под разные архитектуры? Или к нему тоже нужен тулчейн?

А версия ядра не влияет? Если в дистрибе малинки была одна версия, а я запускаю qemu-chroot на другой

Я работал с ARM XScale только. На ARMv7 должно запуститься скомпилированное под ARMv6. Попробуй?
Clang для ARM тоже требует тулчейн, например этот - https://github.com/eblot/clang4arm.
Ну и советую использовать для начала статическую линковку для проверки.

Ага. Средствами самой «малинки» дольше получается. Ну и еще плюс — у меня всегда свежий образ под рукой, несмотря на то, что железяка может хрен знает где работать без доступа по сети...

В жизни бы сам не додумался до такого извращения )

Почему же «извращения»? Образ-то нужно в актуальном состоянии поддерживать. Если для распбиана пофиг еще, то уж генту на кубитрак я обновляю на компе. Хотя, надо будет попробовать присобачить SSD к кубитраку и сравнить скорость, есть подозрение, что мощей кубитрака хватит, чтобы генту компилять шустрей, нежели на компе в qemu-вском чруте.

В хорошем смысле извращения. Тоже так буду делать. В процессе сборки pacman-пакета, будет запускаться qemu, на нем компилироваться либа и засовываться в пакет. Надеюсь, это реализуемо на баше. Качать мутные тулчейны желания почему-то нет)

Подскажи, /usr/bin/qemu-arm-static ведь должен лежать в choot-овом каталоге. А qemu на хостовой машине, получается и не нужен вовсе?

А если в моем арчике qemu-arm-static нету (только qemu-arm) - ничего не получится? (AUR не предлагать)

Получается так, но я не пробовал без qemu на хосте.

А если в моем арчике qemu-arm-static нету

В моем рачике тоже не было, стандартно ставится из дебьяновского пакета.

спасибо

http://raspberrypi.stackexchange.com/questions/855/is-it-possible-to-update-u...

Кстати, чего нагуглил-то: только что сделал апгрейд образа и тупым cp обновил содержимое флешки. Гружусь — хрена с 2! Сейчас поставил полное копирование образа на флешку при помощи dd, а буквально через 2 минуты вспомнил, что я болван:

You should remove qemu-user-static from /usr/bin or qemu-arm from /usr/local/bin on the RPi, then the image is ready to be flashed.

Вот тебе грабли — не натыкайся.

Меня не прельщают подобные полумеры (компиляция qemu-user-static из исходников или выдирание из левого пакета). Буду обмазываться всякими devicetree и uboot и пытаться запустить через qemu-system-arm. В прошлый раз, правда, ничего не вышло.. )

А почему qemu-user-static на флешке мешает образу запуститься?

Делать тебе нехрен.

А рачик бросай. Негоже это такой шлак вместо линукса использовать. Гента же есть. И на кубитраке генточка отлично себя чувствует.

А почему qemu-user-static на флешке мешает образу запуститься?

Потому что он пытается все инструкции на x86_64 транслировать, а камушек-то на деле — ARM!

возьми из какой-нить OpenWRT. там точно есть тулчейны для ARM и они стопудово работают.

Гента же есть

А они до сих пор пытаются отделить udev от systemd и всячески дискредетировать последний?)

В OpenWRT тулчейн есть. А нормального пакетного менеджера, кучи пакетов и прочих удобств - нет )

На тебе еще скриптик для компиляния ведра под малинку на x86:

#!/bin/bash
export CCPREFIX=/usr/bin/arm-none-eabi-
export MODULES_TEMP=Modules

make ARCH=arm CROSS_COMPILE=${CCPREFIX}
make ARCH=arm CROSS_COMPILE=${CCPREFIX} modules
mkdir ${MODULES_TEMP}
make ARCH=arm CROSS_COMPILE=${CCPREFIX} INSTALL_MOD_PATH=${MODULES_TEMP} modules_install

Они молодцы. Поцтерошлак не внедряют.

Если внедрят, перейду на слаку. А как и Патрег говном станет, пойду на бздю. Но подставлять задницу всяким гомосекам я не собираюсь!

дык, тебе шашечки или ехать? кросскомпиляция - это не общепит. кто тебе будеть пакетировать всё подряд под все архитектуры? хочешь стать майнтейнером пакета - вперёд. только обычно все сами себе собирают компиляторы, под свои нужды.

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

О как. Это получается Make-файл ядра идет с поддержкой кросс-компиляции?

Ну не знаю. Тот же systemd-nspawn мне показался удобнее и функциональнее chroot.

А с помошью нехитрых настроек можно неплохо так изолировать приложения. Как по мне - так сплошной профит )