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, от которого изначально всё пошло. В него для поддержки loongarch64 нужно добавить файлик.
modernc.org/*
Что-то похожее на начальную поддержку loongarch64 появилось в modernc.org/libc v1.24.1. Хватит ли этого для работы конкретного пакета -- непонятно.
modernc.org/sqlite, modernc.org/tcl, ... -- всё ещё сложнее: https://gitlab.com/cznic/sqlite/-/merge_requests/58
rust
rust под loongarch64 работает, rust под loongarch64 хорош.
Однако часто встречаются довольно старые версии завендоренных зависимостей, которые ещё не знают про loongarch64.
Тогда можно обновить версию в Cargo.lock, например так:
cargo update --precise 0.12.7 -p target-lexicon
Затем закоммитить и перевендорить зависимости.
Другой вариант решения проблемы -- приложить патч (примеры ниже). Патчи на многие библиотеки тривиальны и добавляют одну-две строки в понятных местах. Однако для завендоренных зависимостей cargo хранит контрольные суммы файлов, поэтому, помимо применения патчей, нужно поправить соответсвующий .cargo-checksum.json. Есть вариант пересчитать контрольные суммы при помощи cargo-vendor-checksum; но часто проще удалить контрольные суммы файлов, cargo на это не ругается, примерно так:
# allow patching vendored rust code
sed -i -e 's/"files":{[^}]*}/"files":{}/' \
./path/to/.cargo-checksum.json
nix
Pull request пока (2023-11-17) не принят, пример патча.
target-lexicon
Нужна версия 0.12.7 или новее.
rustix
Поддержка loongarch64 появилась в версии 0.38.5 (ce0d97e75). Однако может оказаться проще приложить патч.
qt5-webengine, qt6-webengine
Нет и в ближайшее время не предвидится. Если в пакете используются rpm-macros-qt5-webengine (или, соответсвенно, rpm-macros-qt6-webengine для Qt6), всё должно работать само. Если нет, переходите на эти макросы (например так).