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)

В Arch Linux есть:

Репозиторий          : extra
Название             : aarch64-linux-gnu-gcc
Версия               : 15.1.0-2
Описание             : The GNU Compiler Collection - cross compiler for ARM64 target
Архитектура          : x86_64
URL                  : https://gcc.gnu.org/
Лицензии             : GPL  LGPL  FDL
Группы               : Нет
Предоставляет        : Нет
Зависит от           : aarch64-linux-gnu-binutils  aarch64-linux-gnu-glibc  libmpc  zlib  libisl  zstd
Доп. зависимости     : Нет
Конфликтует с        : Нет
Заменяет             : Нет
Размер загрузки      : 82,96 MiB
Установленный размер : 378,21 MiB
Сборщик              : Robin Candau <antiz@archlinux.org>
Дата сборки          : Чт 17 июл 2025 14:09:34
Проверен             : SHA-256  Подпись

Репозиторий          : extra
Название             : arm-none-eabi-gcc
Версия               : 14.2.0-1
Описание             : The GNU Compiler Collection - cross compiler for ARM EABI (bare-metal) target
Архитектура          : x86_64
URL                  : https://gcc.gnu.org/
Лицензии             : GPL  LGPL  FDL
Группы               : Нет
Предоставляет        : Нет
Зависит от           : arm-none-eabi-binutils  zlib  libmpc  libisl  zstd
Доп. зависимости     : arm-none-eabi-newlib: Standard C library optimized for embedded systems
Конфликтует с        : Нет
Заменяет             : Нет
Размер загрузки      : 237,83 MiB
Установленный размер : 1769,30 MiB
Сборщик              : Anatol Pomozov <anatolik@archlinux.org>
Дата сборки          : Пн 25 ноя 2024 03:41:15
Проверен             : SHA-256  Подпись

Репозиторий          : extra
Название             : lm32-elf-gcc
Версия               : 14.1.0-1
Описание             : The GNU Compiler Collection - cross compiler for LatticeMico32 (bare-metal) target
Архитектура          : x86_64
URL                  : https://gcc.gnu.org/
Лицензии             : GPL-3.0-with-GCC-exception AND GFDL-1.3-or-later
Группы               : Нет
Предоставляет        : Нет
Зависит от           : lm32-elf-binutils  zlib  libmpc  libisl  zstd
Доп. зависимости     : lm32-elf-newlib: Standard C library optimized for embedded systems
Конфликтует с        : Нет
Заменяет             : Нет
Размер загрузки      : 38,71 MiB
Установленный размер : 554,43 MiB
Сборщик              : Filipe Laíns <lains@archlinux.org>
Дата сборки          : Ср 05 июн 2024 03:35:44
Проверен             : SHA-256  Подпись

Репозиторий          : extra
Название             : nds32le-elf-gcc
Версия               : 14.1.0-1
Описание             : The GNU Compiler Collection - cross compiler for Andes 32 little-endian (bare-metal) target
Архитектура          : x86_64
URL                  : https://gcc.gnu.org/
Лицензии             : GPL-3.0-with-GCC-exception AND GFDL-1.3-or-later
Группы               : Нет
Предоставляет        : Нет
Зависит от           : nds32le-elf-binutils  zlib  libmpc  libisl  zstd
Доп. зависимости     : nds32le-elf-newlib: Standard C library optimized for embedded systems
Конфликтует с        : Нет
Заменяет             : Нет
Размер загрузки      : 58,41 MiB
Установленный размер : 353,66 MiB
Сборщик              : Filipe Laíns <lains@archlinux.org>
Дата сборки          : Ср 05 июн 2024 03:37:13
Проверен             : SHA-256  Подпись

Репозиторий          : extra
Название             : or1k-elf-gcc
Версия               : 14.1.0-1
Описание             : The GNU Compiler Collection - cross compiler for OpenRISC 1000 (bare-metal) target
Архитектура          : x86_64
URL                  : https://gcc.gnu.org/
Лицензии             : GPL-3.0-with-GCC-exception AND GFDL-1.3-or-later
Группы               : Нет
Предоставляет        : Нет
Зависит от           : or1k-elf-binutils  zlib  libmpc  libisl  zstd
Доп. зависимости     : or1k-elf-newlib: Standard C library optimized for embedded systems
Конфликтует с        : Нет
Заменяет             : Нет
Размер загрузки      : 30,53 MiB
Установленный размер : 335,39 MiB
Сборщик              : Filipe Laíns <lains@archlinux.org>
Дата сборки          : Ср 05 июн 2024 03:37:27
Проверен             : SHA-256  Подпись

Репозиторий          : extra
Название             : riscv64-elf-gcc
Версия               : 14.1.0-1
Описание             : The GNU Compiler Collection - cross compiler for RISCV64 (bare-metal) target
Архитектура          : x86_64
URL                  : https://gcc.gnu.org/
Лицензии             : GPL-3.0-with-GCC-exception AND GFDL-1.3-or-later
Группы               : Нет
Предоставляет        : Нет
Зависит от           : riscv64-elf-binutils  zlib  libmpc  libisl  zstd
Доп. зависимости     : riscv64-elf-newlib: Standard C library optimized for embedded systems
Конфликтует с        : Нет
Заменяет             : Нет
Размер загрузки      : 117,05 MiB
Установленный размер : 667,18 MiB
Сборщик              : Filipe Laíns <lains@archlinux.org>
Дата сборки          : Ср 05 июн 2024 03:37:19
Проверен             : SHA-256  Подпись

Репозиторий          : extra
Название             : riscv64-linux-gnu-gcc
Версия               : 15.1.0-2
Описание             : Cross compiler for 32-bit and 64-bit RISC-V
Архитектура          : x86_64
URL                  : https://gcc.gnu.org/
Лицензии             : GPL  LGPL  FDL
Группы               : risc-v
Предоставляет        : Нет
Зависит от           : riscv64-linux-gnu-binutils  riscv64-linux-gnu-glibc  gcc-libs  glibc  gmp  libisl  libisl.so=23-64  libmpc  mpfr  libmpfr.so=6-64  zlib  libz.so=1-64  zstd  libzstd.so=1-64
Доп. зависимости     : Нет
Конфликтует с        : Нет
Заменяет             : Нет
Размер загрузки      : 96,77 MiB
Установленный размер : 556,24 MiB
Сборщик              : Robin Candau <antiz@archlinux.org>
Дата сборки          : Чт 17 июл 2025 16:00:54
Проверен             : SHA-256  Подпись

Репозиторий          : extra
Название             : ruby-rake-compiler-dock
Версия               : 1.10.0-1
Описание             : Easy to use and reliable cross compiler environment for building Windows, Linux, Mac and JRuby binary gems
Архитектура          : any
URL                  : https://github.com/rake-compiler/rake-compiler-dock
Лицензии             : MIT
Группы               : Нет
Предоставляет        : Нет
Зависит от           : ruby
Доп. зависимости     : Нет
Конфликтует с        : Нет
Заменяет             : Нет
Размер загрузки      : 44,21 KiB
Установленный размер : 188,01 KiB
Сборщик              : Andreas Schleifer <segaja@archlinux.org>
Дата сборки          : Сб 25 окт 2025 15:01:31
Проверен             : SHA-256  Подпись

Но проще это организовать в source-based дистрибутивах, там уже под кросс-комиляцию многое подготовлено обычно. Вот один из случаев кросс-компиляции в Арче, но то было организовать сравнительно просто – всё необходимое было в репозиториях.

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

Т.е. из коробки полноценного multi-arch нет более нигде? В других дистрибутивах придётся что-то дополнительно собирать руками и патчить спецификации сборки пакетов имеющейся архитектуры под целевую?

Кроме разве что ubuntu, но в данном ключе этот тот же Debian.

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

Для другой архитектуры, эмулировать через qemu-user? Это очень медленно, примерно в 5-6 раз медленней нативного выполнения. Сильно повлияет на скорость компиляции.

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

Это же только кросс-компилятор, он есть в любом более-менее устоявшемся дистрибутиве.

У меня есть программа с 3 зависимостями, присутствующая в репозитории ArchLinux. Что мне сделать, чтобы собрать её на x86_64 для ARM64, не компилируя эти зависимости вручную для ARM64 (не создавая свой sysroot)?

В Debian достаточно указать архитектуру пакета при apt install, чтобы он скачался и установился. Библиотеки и заголовочные файлы разных архитектур не конфликтуют.

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

В общем, нужно установить binutils, gcc, glibc, linux-api-headers для целевой платформы на машину, на которой будет производиться компиляция, для aarch64, например, это следующие пакеты:

aarch64-linux-gnu-binutils
aarch64-linux-gnu-gcc
aarch64-linux-gnu-glibc
aarch64-linux-gnu-linux-api-headers

Нужно установить их, внести необходимые изменения в PKGBUILD-ы пакетов и makepkg.conf и собрать, как в шаге 7 выше по ссылке.

yars068 ★★★★★
()
Последнее исправление: yars068 (всего исправлений: 3)
Ответ на: комментарий от yars068

Вот один из случаев кросс-компиляции в Арче, но то было организовать сравнительно просто – всё необходимое было в репозиториях.

Ваш пример по ссылке показывает, что архитектурно кросс-компиляция не поддерживается: makepkg не может сам указать PKGBUILD’у нужный компилятор в переменных окружения, удостовериться, что будут использоваться правильные заголовочные файлы, а вам приходится модифицировать файл вручную.

В Debian не нужно редактировать сборочные файлы, за настройку среды сборки отвечает dpkg-buildpackage. Он делает буквально всё: от конфигурирования пакета до его сборки и установки.
Система сборки Debian сама определяет сборочную среду пакета (autotools, cmake, qmake, meson/ninja, ant, python distutils, и т.п.), настраивает переменные окружения с компиляторами и флагами, а если нужна кросс-компиляция, подсовывает необходимые настройки сама (для cmake/qmake это toolchain-файл, для других систем это необходимые флаги).

Но ДО процесса компиляции нужно ещё установить зависимости. В Debian библиотеки собраны так, что каждая использует свой архитектурно-зависимый путь в /usr/lib/[arch], и поэтому не конфликтует с такими же библиотеками другой архитектуры. В ArchLinux, полагаю, придётся либо компилировать библиотеку самостоятельно и указывать её путь флагами компиляции, либо скачивать готовую и распаковывать в нестандартную папку, и также указывать её путь в -I, -L.

В Fedora, например, есть поддержка x86_64 и i686 multilib: первые устанавливаются в /usr/lib64, вторые в /usr/lib. Но, похоже, третью архитектуру, aarch64, так не установить, в пакетах используются те же /usr/lib[64].

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

Нужно установить их, внести необходимые изменения в PKGBUILD-ы пакетов и makepkg.conf и собрать, как в шаге 7 выше по ссылке.

Вы хотите пересобрать Firefox под ARM64 с дополнительным патчем, на вашем Intel-компьютере. У Firefox 56 зависимостей. Как вы поступите?

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

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

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

Вот, к примеру я собирал asterisk на Debian под armhf (RPI3) с Debian 12.

# Добавить srс репозитории
vim /etc/apt/sources.list.d/debian.sources
dpkg --add-architecture armhf
apt update
apt install -y dpkg-dev devscripts debhelper dirmngr build-essential crossbuild-essential-armhf gcc-arm-linux-gnueabihf g++-arm-linux-gnueabihf pkg-config
mkdir src
cd src
dget http://ftp.debian.org/debian/pool/main/a/asterisk/asterisk_22.6.0~dfsg+~cs6.15.60671435-1.dsc
cd asterisk-22.6.0~dfsg+~cs6.15.60671435/
apt-get build-dep -y --arch-only -a armhf .
apt-cache policy libc6:armhf
apt-cache policy libopenr2-dev:armhf
apt-cache policy binutils-dev:armhf
apt-cache policy perl:armhf
apt-cache policy portaudio19-dev:armhf
apt-cache policy systemd-dev:armhf
apt install -y libxml2-dev libxml2-dev:armhf libxml2:armhf
vim debian/control
dpkg-checkbuilddeps
debuild -B -a armhf -b -uc -us

Какие-то нюансы пропустил, но в целом примерно так. Ничего собирать отдельно не пришлось. С учётом, что asterisk в репозитории Debian 12 вообще нет. Все патчи применились, проверки так же прошли успешно. Правки в control - убрана зависимость systemd-dev или что-то вроде того, в 12 версии по другому. dsc файл был или из sid или из unstable.

Ещё правки changes, чтобы написано было то, что мне нужно.

Сборка проводилась в docker контейнере, чтобы потом из основной системы не нужно было удалять более не требующиеся мне пакеты, образ контейнера на базе Debian 12.

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

Я собираю под отдельным юзером, а пакеты легко и непринуждённо удаляются pacman -Rncs, или pacman -Rnd. Впрочем, у pacman есть ключ --arch, но я им не пользовался, так как в документации, в частности, в man его описание крайне скупо.

Ну и, насколько вижу, править сборочные файлы есть нужда, так она частенько нужна.

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

Так в любом линуксе можно, вопрос только в размере напильника. Это хорошо, что в Debian разработчики провели такую большую работу по облегчению кросс-компиляции (и компиляции в целом), но иногда лучше-проще сделать всю работу самому, и для этого подходят source-based дистрибутивы, вот там всё максимально оптимизировано для сборки из исходников.

yars068 ★★★★★
()

Вопрос: есть ли подобное в других дистрибутивах?

Есть. man mock. Сборка rpm — одна команда:

$ mock --chroot OS-ARCH --rebuild SRPM

Выкачивает всё что надо и строит пакет не засоряя основную систему.

$ mock --list-chroots | wc -l 
244

$ mock --list-chroots | perl -ne 'm/^([^-+]*)-/ and print "$1\n";' | sort | uniq
alma
almalinux
amazonlinux
anolis
azure
centos
circlelinux
custom
epel
fedora
hermetic
kylin
mageia
navy
openeuler
openmandriva
opensuse
oraclelinux
rhel
rocky

$ mock --list-chroots | perl -ne 'm/^\S*?-([^-\s]+) / and print "$1\n";' | sort | uniq
aarch64
armhfp
armv7hl
armv7hnl
build
i386
i586
i686
loongarch64
ppc64
ppc64le
riscv64
s390
s390x
x86_64
x86_64_v2

~20 дистрибутивов, ~15 архитектур, ~240 платформ. Всё из коробки. F42.

P. S. Не всё, но большая часть из перечисленного доступна в copr — федоровской билд-ферме. Там одной командой copr build SRPM... можно построить несколько пакетов для множества платформ.

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

https://wiki.gentoo.org/wiki/Cross_build_environment

и/или

util-linux 2.42-start-521-ec46 2025-08-09 UNSHARE(1)

The following example execute a chroot into the directory /chroot/powerpc/jessie and install the interpreter /bin/qemu-ppc-static to execute the powerpc binaries.

       $  unshare --map-root-user --fork --pid --load-interp=":qemu-ppc:M::\\x7fELF\x01\\x02\\x01\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x02\\x00\\x14:\\xff\\xff\\xff\\xff\\xff\\xff\\xff\\x00\\xff\\xff\\xff\\xff\\xff\\xff\\xff\\xff\\xff\\xfe\\xff\\xff:/bin/qemu-ppc-static:OCF" --root=/chroot/powerpc/jessie /bin/bash -l

   The load-interp parameter can be read as following

       qemu-ppc
           is the name of the new file created below
           /proc/sys/fs/binfmt_misc to register the interpreter

       M
           defines the interpreter for a given type of magic number

       \\x7fELF\x01\\x02\\x01\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x02\\x00\\x1
           is the magic number to recognize the file to interpret (in
           this case, the ELF header for PPC32)

       \\xff\\xff\\xff\\xff\\xff\\xff\\xff\\x00\\xff\\xff\\xff\\xff\\xff\\xff\\xff\\xff\\xff\\xfe\\xff\\xff
           the mask to apply to the magic number

       /bin/qemu-ppc-static
           the interpreter to use with the file

       OCF
           the file is open by the kernel with credential and
           security tokens of the file itself and loaded as soon as
           we register it.

поёдет?

anonymous
()
Ответ на: комментарий от yars068

Извиняюсь, хотел уточнить, что distcc еще мейнтайнер должен приркутить: не все пакеты умеют в distcc. И уточняющий вопрос, в принципе, если есть generic для ARM то (лично мне кажется, не претендую на истину) стоит начать с него.

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

не все ручки и рычажки стоит крутить. Да есть проблема, что задача узкого спектра и информацию особо никто не выкладывает… методом проб и ошибок

anonymous
()
Ответ на: комментарий от Ja-Ja-Hey-Ho

Вопрос же про кросс-компиляцию был, в mock сборка других архитектур происходит в VM.

Тебе и ТСу шашечки или ехать? Я так понял, что цель — собрать пакет для другой архитектуры. VM или не VM — это детали.

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

Мне шашечки, конечно. Я дистрибутив запустить в qemu под другой архитектурой и сам могу, без использования сторонних средств. Речь о кросс-компиляции, а не о компиляции в виртуалке.

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

Если выстраивать конвеер релиза для нескольких дистров, то всё равно может быть проще qemu через готовую обёртку docker/podman buildx для каждого из дистров. Универсального или хотя бы мейнстримного решения для основных дистров не видно.

А если для дома, для семьи, так верно — лучше Debian ничего нет.

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

Ну, извини. Я думал, что тебе интересно как в других дистрах пакеты одной командой строят, а ты, оказывается, на дебиан хотел подрочить. Не буду мешать.

P. S. Я, кстати, там ошибся в одной опции: чтобы указать платформу, для которой строить, надо использовать -r OS-ARCH а не --chroot OS-ARCH.

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

Для другой архитектуры, эмулировать через qemu-user? Это очень медленно, примерно в 5-6 раз медленней нативного выполнения

Так никто ж всерьёз не компилирует «в виртуалке». Для изоляции используется Docker, либо ещё какое–нибудь решение, основанное на контейнерах, нэймспейсах или хотя бы chroot. Оверхед там минимален, по сравнению с виртуализацией.

И уже в изолированной среде разворачиваются кросс–компилирующие тулчейны под целевую платформу — buildroot, mock, crossdev или что там больше по душе. И незачем захламлять хостовую систему и требовать невозможного (поддержки на всё это экзотические хозяйство) от мэйнтейнеров универсального дистрибутива.

Если debian поддерживает в основном дереве кросскомпиляцию для ряда архитектур, для которых они сами собирают релизы, это ж не значит, что поддерживается абстрактная кросскомпиляция вообще. Можно ли там с такой же лёгкостью собрать бинарник под SuperH, 6502, M68K или AVR (не притаскивая очевидные clang/LLVM)?

Quote
()
Ответ на: комментарий от debugger

В первом сообщении достаточно точно описан вопрос, мне нечего добавить.

То, что в эмуляции можно запустить любой дистрибутив и собрать пакет под запущенную архитектуру, потеряв в производительности в 5-6 раз в лучшем случае, очевидно. Это можно сделать в qemu, без дополнительных программ.

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

а не компилировать их самостоятельно в своём sysroot, и не запускать компиляторы в qemu-user?

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

И уже в изолированной среде разворачиваются кросс–компилирующие тулчейны под целевую платформу — buildroot, mock, crossdev

Не уверен, что понял вас. Разверните идею.

Buildroot и crossdev соберут вам кросс-компилирующий тулчейн (скомпилируют gcc/clang + libc + минимальный sysroot под необходимую целевую архитектуру). Можно как-то выполнить только этот этап, чтобы далее использовать уже собранные библиотеки какого-то дистрибутива в рамках этого тулчейна, там, где кросс-компилятор отсутствует в репозитории?

Buildroot и crossdev совершенно точно не автоматизируют этот процесс с точностью до дистрибутива (использование конкретной версии glibc из конкретного дистрибутива, с необходимыми опциями, путями и патчами), а иначе будут проблемы с совместимостью бинарных пакетов (библиотек) дистрибутива.

Так никто ж всерьёз не компилирует «в виртуалке»

Как мы выяснили в этой теме, похоже, все только так и компилируют :D

Если debian поддерживает в основном дереве кросскомпиляцию для ряда архитектур, для которых они сами собирают релизы, это ж не значит, что поддерживается абстрактная кросскомпиляция вообще

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

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

Я могу то же самое сделать, скажем, в mock для fedora? Как?

Установил, забутстрапил fedora-43-aarch64, получил запуск ./configure в qemu-aarch64-static, выполняющегося со скоростью улитки: https://0x0.st/P8Zi.avif

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

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

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

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

Ну если они по ABI подойдут - то в принципе можно. Но потребуется ОЧЕНЬ много ручной работы.

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

Ну, так, как оно работает-то? Это же только сборочная система, верно? Как она «добавит» кросс-компилятор в те дистрибутивы, где он отсутствует в репозитории?

Иными словами, можете привести пример, как я могу выполнить кросс-компиляцию пакета hello (GNU hello world) под ARM64 на x86_64 в Fedora, используя OBS?

Эмуляцией чего?

Эмуляцией процессора архитектуры назначения, chroot которой используется, бинарники из которого запускаются.

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

Увы, но остаётся только такой вариант https://bellard.org/jslinux/ Если серьёзно и без шуток, мы все прекрасно помним времена 32/64 бит и очевидно, что на https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html «свежих» процессорах можно собирать под более ранние процессоры, - это направление в сторону верности использования паравиртуализации для сборки, чем использовать chroot + namespace/cgroup являющиеся ПОДСИСТЕМОЙ ХОСТА (честно надеялся на то что ребята сами себя поправят) и очевидно такой ровно как и любой «контейнер» как бы он не был заизолирован «работает от ядра» хоста (Докеристы, вы там попробуйте что-то вроде tun в своих контейнерах сделать и не получить по рукам от ядра хоста. Молчу про садоми… тифу системдэмщиков, маны от unshare, pivot_root, switch_root и сами утилиты перепишут и поставят «одобрено для systemd» поверю) только в виде бинарник qemu как «интепритатор архитектуры» если так уместно выразиться может попытаться решить узкую задачку. Мысль мог потерять, отвлекся. Вроде все что посчитал существенным озвучил.

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

Чтобы ге было «потери в производительности в 5-6 раз в лучшем случае», делается гибридный сетап, где компилятор исполняется как наивный бинарь на хосте, а остальной код - в эмуляции.

Это позволяет выполнить кроссбилд без лишних заморочек.

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

Мы как будто какой-то ритуал пляшем, ходим вокруг да около.

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

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

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

А… Тогда прошу прощения, что ворвался в дискуссию. В этом плане да, Дебиан скорее исключение. Имелось в виду, что у многих дистрибутивов есть так или иначе кросс-тулчейн, но он не предполагается к повседневному использованию как часть хостовой системы. Скорее к разворачиванию в отдельном контейнере или на билд–ферме.

Насчёт redhat–based ничего не могу сказать. В той же Gentoo crossdev есть, но использовать его… мягко говоря, нетривиально. Хотя бы потому, что для разных профилей и разных архитектур далеко не все пакеты можно поставить и не со всеми флагами их можно собрать. Поэтому для каждого профиля/архитектуры придётся создавать своё окружение.

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

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

Кросскомпилятор собрать нн проблема.

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

Описанный мной вариант эти проблемы убирает.

Про конкретику ничего не скажу, я описал общий принцип. Не моя тема.

Отправь это нейросети, она тебе хоть на 5 страниц подробностей расскажет.

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

Поддерживаю. Поэтому выше из таких же соображений предположил про потенциальный generic, который будет выступать максимально младшей и по определению наиболее «кроссплатформенной» для такой архитектуры результатом сборки.

anonymous
()
Ответ на: комментарий от wandrien

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

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