Ports/loongarch64/Porting
Здесь описаны замечания и рекомендации по исправлению сборки пакетов Сизифа на loongarch64.
Общие замечания
loongarch64 -- архитектура, содержащая на удивление немного сюрпризов и подвохов с точки зрения переносимого кода на linux. Обычный, не слишком низкоуровневый код, чаще всего просто собирается и работает.
Проблемы сборки пакетов, уже успешно работающих на 3-4 архитектурах, обычно связаны с тем, что loongarch64 появилась сравнительно недавно и её поддержка просочилась ещё не во все архитектурно-специфичные компоненты.
C/C++
loongarch64 -- little endian, char по умолчанию signed.
Чтобы понять, что Вы на loongarch64, нужно посмотреть на символ __loongarch__ и убедиться, что __loongarch_grlen равен 64 (как-то так). Если важно именно ABI, смотрите на __loongarch_lp64d. Обо всём этом можно прочитать в документации.
cannot find 'ld'
Пример ошибки:
collect2: fatal error: cannot find 'ld' compilation terminated.
Чаще всего возникает, когда пакет, не проверив, пытается использовать gold. gold на loongarch64 нет, он даже не собирается. Отрывайте.
gcc 10, llvm 12 и сотоварищи
Полноценная поддержка (и вообще поддержка) loongarch64 появилась в GCC 13 и llvm 16.0. Соответственно, более ранних версий этих тулчейнов под loongarch64 нет и не предвидится.
Если какой-то пакет сборочно зависит, например, от gcc12, посмотрите, может он ему не так уж и нужен (пример). Если всё-таки нужен, excludearch неизбежен.
clang/llvm/lld
clang 16.0 и 17.0 не особо поддерживают LSX и LASX (SIMD extensions). Если кто-то их где-то уже пытается применить, отрывайте.
LLD (LLVM linker) не поддерживает многих нужных релокаций и пока (as of 17.0) не умеет в релаксации вообще. clang 17 собран так, чтобы по умолчанию использовать ld.bfd (GNU binutils), так что если вы видите ошибку вроде такой:
ld.lld: error: /usr/bin/../lib64/gcc/loongarch64-alt-linux/13/../../../../lib64/Scrt1.o:(.text+0x0): unknown relocation (102) against symbol clang: error: linker command failed with exit code 1 (use -v to see invocation)
то кто-то явно передал clang'у -fuse-ld=lld. Уберите эту опцию и всё соберётся.
autotools
Чаще всего проблема в том, что в пакете лежат слишком старые config.guess и config.sub. Ошибка сборки может выглядеть, например, так:
configure: error: cannot guess build type; you must specify one
Если в пакете используется %autoreconf, то такой проблемы быть не должно; если нет, лучше сделать чтобы использовался, хотя для этого иногда приходится проявить изобретательность. Ничего плохого от этого обычно не происходит, а вот хорошее может.
Если с %autoreconf ничего не выходит, можно найти в пакете config.guess и config.sub и заменить их на свежие, системные, самым простым способом:
cp -f /usr/share/autoconf/build-aux/config.{guess,sub} ./где/они/тут
autotools vs boost
Пример ошибки:
checking whether the Boost::System library is available... yes configure: error: Could not find a version of the library!
Приложите патч, например так.
golang
golang на loongarch64 работает. Архитектура в терминах Google называется loong64.
В логах упавшей сборки стоит поискать слово undefined: (примеры ниже).
Условная сборка
Иногда достаточно объяснить компилятору, какие файлы брать. Для этого в go используются особые директивы в специальных комментариях: пример.
Обновление завендоренного
Часто достаточно обновить завендоренный код до чуть более нового выпуска, в котором поддержка loongarch64 уже добавлена. Просто взять последнюю получается не всегда, так как для этого, например, пришось бы поднять требуемую версию go в проекте, что не всегда хорошо. Приходится искать что-то, что уже поддерживает loong64, но ещё не требует свежести от go.
Если есть go.mod, то обновить завендоренный модуль можно примерно так:
go get 'golang.org/x/sys@v0.0.0-20220712014510-0a85c31ab51e' go mod tidy rm -rf vendor go mod vendor
Каталог vendor часто присутствует в .gitignore, так что нужны специальные меры:
git add -f vendor git commit -a
И проверьте, что ничего нужного не осталось:
git clean -nxd
Можно править спек и собирать пакет.
Если нет go.mod, импровизируйте.
golang.org/x/sys
Пример ошибки:
[...] vendor/golang.org/x/sys/unix/ztypes_linux.go:22:11: undefined: Timespec vendor/golang.org/x/sys/unix/ztypes_linux.go:23:11: undefined: Timespec vendor/golang.org/x/sys/unix/ztypes_linux.go:1112:12: undefined: SockaddrStorage [...]
Поддержка loongarch64 в golang.org/x/sys появилась в 2022 году, более старые версии нужно обновить. Мы успешно использовали версию golang.org/x/sys@v0.0.0-20220712014510-0a85c31ab51e
github.com/cilium/ebpf
Пример ошибки:
../../vendor/github.com/cilium/ebpf/internal/vdso.go:64:28: undefined: NativeEndian
github.com/cilium/ebpf получил поддержку loongarch64 в версии 0.11.0, однако в ней немало breaking changes в API, поэтому старые (чаще всего 0.9+) версии луше не обновлять, а приложить тривальный патч, например так.
go.etcd.io/bbolt
Пример ошибки:
vendor/go.etcd.io/bbolt/db.go:440:10: undefined: maxMapSize vendor/go.etcd.io/bbolt/db.go:441:8: undefined: maxMapSize vendor/go.etcd.io/bbolt/bolt_unix.go:68:15: undefined array length maxMapSize or missing type constraint
Поддержка loongarch64 появилась в 1.3.7, можно попробовать обновиться, иногда получается.
github.com/boltdb/bolt
Неповторимый оригинал go.etcd.io/bbolt, который был заброшен и форкнут. В него для поддержки loongarch64 нужно добавить файлик.
modernc.org/*
Что-то похожее на начальную поддержку loongarch64 появилось в modernc.org/libc v1.24.1. Хватит ли этого для работы конкретного пакета -- непонятно.
modernc.org/sqlite modernc.org/tcl, ... -- поддержка заявлена в версии 1.29.7: https://pkg.go.dev/modernc.org/sqlite@v1.29.7#hdr-Supported_platforms_and_architectures
github.com/u-root/uio
vendor/github.com/u-root/uio/uio/buffer.go:176:19: undefined: ubinary.NativeEndian
Надо объяснить, какая endianes сейчас у платформы. Новые версии берут её из golang.org/x/sys/cpu, для более старых есть патч.
rust
rust под loongarch64 работает, rust под loongarch64 хорош.
Однако часто встречаются довольно старые версии завендоренных зависимостей, которые ещё не знают про loongarch64.
Тогда можно обновить версию в Cargo.lock, например так:
cargo update --precise 0.12.7 -p target-lexicon
Затем закоммитить и перевендорить зависимости.
Другой вариант решения проблемы -- приложить патч (примеры ниже). Патчи на многие библиотеки тривиальны и добавляют одну-две строки в понятных местах. Однако для завендоренных зависимостей cargo хранит контрольные суммы файлов, поэтому, помимо применения патчей, нужно поправить соответсвующий .cargo-checksum.json.
Можно пересчитать контрольные суммы при помощи cargo-vendor-checksum, например так:
%patch3500 -p1 diffstat -p1 -l < %PATCH3500 | sed -re 's@vendor/@@' | xargs cargo-vendor-checksum -f
Не забудьте добавить сборочные зависимости на cargo-vendor-checksum и diffstat.
Часто проще удалить контрольные суммы файлов, cargo на это не ругается, примерно так:
# allow patching vendored rust code
sed -i -e 's/"files":{[^}]*}/"files":{}/' \
./path/to/.cargo-checksum.json
libc
Поддержка LoongArch есть в версиях 0.2.144 и новее.
linux-raw-sys
LoongArch поддерживается начиная с версии 0.3.2.
nix
Базовая поддержка появилась в версии 0.27.0, однако приложить патч обычно проще.
target-lexicon
Нужна версия 0.12.7 или новее.
rustix
Поддержка loongarch64 появилась в версии 0.38.5 (ce0d97e75). Однако может оказаться проще приложить патч.
is-terminal
Нужна версия 0.4.12. Предыдущие версии тянут за собой "старые" rustix и linux-raw-sys.
terminal_size
Требуется 0.3.0, более старые зависят от rustix, который не умеет в LoongArch.
qt5-webengine
Нет и в ближайшее время вряд ли будет. Если в пакете используются rpm-macros-qt5-webengine, всё должно работать само. Если нет, переходите на эти макросы (например так).
qt6-webengine собран, пользуйтесь.