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

TBD.

rust

TBD.