Ports/loongarch64/Porting

Здесь описаны замечания и рекомендации по исправлению сборки пакетов Сизифа на loongarch64.

Общие замечания

loongarch64 -- архитектура, содержащая на удивление немного сюрпризов и подвохов с точки зрения переносимого кода на linux. Обычный, не слишком низкоуровневый код, чаще всего просто собирается и работает.

Проблемы сборки пакетов, уже успешно работающих на 3-4 архитектурах, обычно связаны с тем, что loongarch64 появилась сравнительно недавно и её поддержка просочилась ещё не во все архитектурно-специфичные компоненты.

C/C++

char по умолчанию signed.

Чтобы понять, что Вы на loongarch64, нужно посмотреть на символ __loongarch__ и убедиться, что __loongarch_grlen равен 64 (как-то так). Если важно именно ABI, смотрите на __loongarch_lp64d. Обо всём этом можно прочитать в документации.

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). Если кто-то их где-то уже пытается применить, отрывайте или переходите на GCC, там оно по крайней мере собирается.

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} ./где/они/тут

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 нужно добавить файлик.

rust

rust под loongarch64 работает, rust под loongarch64 хорош.

Однако часто встречаются довольно старые версии завендоренных зависимостей, которые ещё не знают про loongarch64.

Тогда можно обновить версию (TBD: до какой?) в Cargo.lock, например так:

  cargo update --precise 0.12.7 -p target-lexicon

Затем закоммитить и перевендорить зависимости.

А можно просто пропатчить, иногда это проще; надо только не забыть обновить .cargo-checksum.json.

qt5-webengine, qt6-webengine

Нет и в ближайшее время не предвидится. Если в пакете используются rpm-macros-qt5-webengine (или, соответсвенно, rpm-macros-qt6-webengine для Qt6), всё должно работать само. Если нет, переходите на эти макросы (например так).