LINUX.ORG.RU

Дистрибутивы с кросс-компиляцией

 


1

3

Я всегда пользовался либо deb-based дистрибутивами для создания уникального окружения, либо же специализированными embedded-ориентированными средами, в которых изначально поддерживается кросс-компиляция и всё с ней связанное.

Однако обнаружил, что, похоже, в классических дистрибутивах, поимимо deb-based, в целом нет поддержки одновременной установки пакетов/библиотек разных архитектур и встроенных инструментов кросс-компиляции в сборочной системе и пакетном менеджере.

Так ли это, или я недостаточно хорошо искал?

Иными словами, в Debian я могу собрать пакет на x86_64 для ARM64 с помощью двух команд:

apt build-dep hello:arm64
dpkg-buildpackage -a arm64

Первая установит зависимости для сборки пакета под архитектуру ARM64 из репозиториев, вторая — соберёт его кросс-компилятором и упакует в пакет.

Для этого не нужно бутстрапить отдельный ARM chroot, gcc sysroot; библиотеки для arm64 установятся в /usr/lib/aarch64-linux-gnu и не будут мешать нативным, находящимся в /usr/lib/x86_64-linux-gnu/. Все программы, исполняющиеся во время сборки, скомпилированы под нативную архитектуру.

Вопрос: есть ли подобное в других дистрибутивах? Более широко: как эффективно кросс-компилировать пакеты в Fedora/RHEL/AlmaLinux и других, т.е. использовать бинарные зависимости из репозиториев, а не компилировать их самостоятельно в своём sysroot, и не запускать компиляторы в qemu-user?

Перемещено hobbit из general

★★★★★

Последнее исправление: ValdikSS (всего исправлений: 2)
Ответ на: комментарий от kott

Установил в OpenSUSE Leap пакет cross-aarch64-gcc11, он вообще сломан и не запускается:

/usr/lib64/gcc/aarch64-suse-linux/11/cc1plus: error while loading shared libraries: libisl.so.15: cannot open shared object file: No such file or directory

Есть у вас пример, как вы собирали пакет с помощью OBS? Вы его собирали локально на x86_64-машине, или на их публичном сервисе? Если второе, то там используются нативные ARM-машины, а не кросс-компиляция.

ValdikSS ★★★★★
() автор топика
Ответ на: комментарий от ValdikSS

Я не вникал, как это работает в самом низу, просто вытягивает пакеты и собирает из самых обычных .dsc .control .rules или .spec.

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

kott ★★★★★
()
Ответ на: комментарий от ValdikSS

куда ты его установил?

вот пример пакета: https://build.opensuse.org/package/show/home:surge-synth-team/surge-xt-nightly

всё это я могу собрать локально, не дёргая виртуалки

как бонус - на сервере сборка тригеррится при коммите/пуллреквесте в апстрим репе на GH

kott ★★★★★
()
Ответ на: комментарий от kott

На локальной машине это можно (и по-умолчанию делается) в кросс-окружении

Вы под локальной машиной понимаете машину такой же архитектуры, или другой? Кросс-окружение в смысле chroot-папка таргет-архитектуры?

Но уже для публичных репов - уже только в виртуалке

Что это значит?

ValdikSS ★★★★★
() автор топика
Ответ на: комментарий от kott

всё это я могу собрать локально, не дёргая виртуалки

Подскажите, как?!

Вот лог сборки вашего пакета для Fedora 43 ARM64 в сервисе OBS: https://build.opensuse.org/public/build/home:surge-synth-team/Fedora_43/aarch64/surge-xt-nightly/_log

Как видно, он не кросс-компилируется, а запускается нативно на ARM-машине (в доп. виртуалке с виртуализацией KVM):

[ 0s] i01-armsrv2 started «build _service:set_version:surge-xt-nightly.spec» at Tue Jan 13 00:51:45 UTC 2026.

Что произойдёт, если вы запустите такую же сборку локально на вашей x86_64-машине? Вы утверждаете, что в сборке не будет задействована эмуляция процессора ARM?

ValdikSS ★★★★★
() автор топика
Последнее исправление: ValdikSS (всего исправлений: 1)

Hasher из ALT умеет указывать архитектуру: hsh --target=aarch64 mypkg-0.0-alt0.src.rpm. При этом используется chroot, в который устанавливаются пакеты из Builddep соответствующей архитектуры.

Я сам не пробовал, но раньше пакты для e2k собирались на x86_64, потому что qemu для e2k не существовало, а нативного сервера у альта не было.

Aceler ★★★★★
()
Ответ на: комментарий от ValdikSS

Вы под локальной машиной понимаете машину такой же архитектуры, или другой? Кросс-окружение в смысле chroot-папка таргет-архитектуры?

я на своём тумблевиде на райзене запускаю osc build Debian_13 aarch64 и получаю пакет для aarch64

делается это в кросс окружении https://bzoltan1.github.io/cross-build-and-packaging/

Что это значит?

вот здесь https://build.opensuse.org/ пакеты для разных архитектур собираются не кроссом, а «нативно»

kott ★★★★★
()
Ответ на: комментарий от kott

куда ты его установил?

Я запустил Docker-контейнер opensuse/leap (Leap 15.6) и выполнил zypper install cross-aarch64-gcc11. Установленный кросс-компилятор не запускается из-за отсутствия библиотеки, если передать ему файл для компиляции (а просто aarch64-suse-linux-g++ --version запускается).

b79a5685c07b:~/build # aarch64-suse-linux-g++ --version
aarch64-suse-linux-g++ (SUSE Linux) 11.3.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

b79a5685c07b:~/build # aarch64-suse-linux-g++ hello.cxx 
/usr/lib64/gcc/aarch64-suse-linux/11/cc1plus: error while loading shared libraries: libisl.so.15: cannot open shared object file: No such file or directory

b79a5685c07b:~/build # cat /etc/os-release 
NAME="openSUSE Leap"
VERSION="15.6"
ID="opensuse-leap"
ID_LIKE="suse opensuse"
VERSION_ID="15.6"
PRETTY_NAME="openSUSE Leap 15.6"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:leap:15.6"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://www.opensuse.org/"
DOCUMENTATION_URL="https://en.opensuse.org/Portal:Leap"
LOGO="distributor-logo-Leap"
ValdikSS ★★★★★
() автор топика
Ответ на: комментарий от kott

я на своём тумблевиде на райзене запускаю osc build Debian_13 aarch64 и получаю пакет для aarch64

Debian поддерживает кросс-компиляцию. Можете приложить лог сборки пакета под Fedora aarch64? Или еще проще: сколько по времени занимает сборка x86_64 fedora и aarch64 fedora? А x86_64 debian и arm64 debian?

делается это в кросс окружении https://bzoltan1.github.io/cross-build-and-packaging/

По ссылке совершенно правильно написано о cross-build and cross-packaging, но все последующие действия намекают, что для ненативной архитектуры используется запуск программ архитектуры в эмуляции, а не кросс-компиляция.

И действительно, в исходнике используется qemu: https://github.com/bzoltan1/sysroot-tools/blob/422d0e8dfb5ceb27303e4989f4ff37b2bc1b332d/sysroot#L1330-L1343

ValdikSS ★★★★★
() автор топика
Ответ на: комментарий от kott

ну так надо всё остальное aarch64 барахло тащить, этим OBS и занимается

aarch64-suse-linux-g++ это бинарник под x86_64. Кросс-компиляторам не нужны ненативные базовые пакеты, вроде libc / libstdcpp. Здесь просто пакет собран в 2022 году (и это, вроде, наиболее актуальная версия?), зависимость обновили, пакет не пересобрали, и автоматика OpenSUSE этого не обнаружила (немудрено — библиотека почему-то загружается динамически, иначе и --version бы не запустился).

ValdikSS ★★★★★
() автор топика
Ответ на: комментарий от ValdikSS

qemu используется как одна из опций, man osc:

`If you’ve set the used VM type in oscrc, it can be also overridden here

       --vm-type=chroot     # for faster, but uncleaner and unsecure build
       --vm-type=kvm        # for clean and secure build
       --vm-type=qemu       # for slow cross architecture build using system emulator`

Можете приложить лог сборки пакета под Fedora aarch64? Или еще проще: сколько по времени занимает сборка x86_64 fedora и aarch64 fedora? А x86_64 debian и arm64 debian?

ну могу, но потом

kott ★★★★★
()
Ответ на: комментарий от kott

qemu[-system] и qemu-user это разные вещи. И то, и то эмулирует процессор, но первое эмулирует еще и машину (материнскую плату и периферию) целиком (с запуском ядра таргета, и пр.)

Имея установленный qemu-user в хост-системе, вы можете выполнять chroot() в ненативную архитектуру. Приложения ненативной архитектуры будут выполняться в эмуляции, медленно.

Именно так и предлагают компилировать программы в другие архитектуры большинство дистрибутивов и сборочных систем — запуском компилятора для таргет-архитектуры через qemu-user (в chroot или без него). Это не кросс-компиляция, это компиляция под эмуляцией. И это медленно.

А в Debian не только есть кросс-компилятор в репозиториях, но и вся сопутствующая инфраструктура, позволяющая просто и эффективно его использовать. Пакеты собираются с такой же скоростью, как и для хост-архитектуры, без эмуляции. И дополнительно Debian не требует создавать chroot таргет-архитектуры — это удобная фишка, но принципиально можно обойтись и без неё.

ValdikSS ★★★★★
() автор топика
Ответ на: комментарий от kott
$ osc build -o Debian_13 aarch64 
WARNING: Using EXPERIMENTAL support for git scm. The functionality may change or disappear without a prior notice!
**WARNING: native compile is not possible, a emulator via binfmt misc handler must be configured!**
ValdikSS ★★★★★
() автор топика
Ответ на: комментарий от Aceler

Хм, кросс-компиляции в скриптах не вижу. Вроде, только вызывается rpmbuild с –target. Возможно, во время бутстрапа применяли доп. хаки, так обычно делают.

ValdikSS ★★★★★
() автор топика