Ports/loongarch64/Porting: различия между версиями

Материал из ALT Linux Wiki
 
(не показано 26 промежуточных версий 2 участников)
Строка 11: Строка 11:
== C/C++ ==
== C/C++ ==


<code>char</code> по умолчанию signed.
loongarch64 -- little endian, <code>char</code> по умолчанию signed.


Чтобы понять, что Вы на loongarch64, нужно посмотреть на символ <code>__loongarch__</code> и убедиться, что <code>__loongarch_grlen</code> равен 64 ([https://git.altlinux.org/people/iv/packages/Mesa.git?a=commitdiff;h=a9f34d7618d2b1c67e3073f10071385f4e25b000 как-то так]). Если важно именно ABI, смотрите на __loongarch_lp64d. Обо всём этом можно прочитать в [https://loongson.github.io/LoongArch-Documentation/LoongArch-toolchain-conventions-EN.html документации].
Чтобы понять, что Вы на loongarch64, нужно посмотреть на символ <code>__loongarch__</code> и убедиться, что <code>__loongarch_grlen</code> равен 64 ([https://git.altlinux.org/people/iv/packages/Mesa.git?a=commitdiff;h=a9f34d7618d2b1c67e3073f10071385f4e25b000 как-то так]). Если важно именно ABI, смотрите на __loongarch_lp64d. Обо всём этом можно прочитать в [https://loongson.github.io/LoongArch-Documentation/LoongArch-toolchain-conventions-EN.html документации].
== cannot find 'ld' ==
Пример ошибки:
collect2: fatal error: cannot find 'ld'
compilation terminated.
Чаще всего возникает, когда пакет, не проверив, пытается использовать gold. <code>gold</code> на loongarch64 нет, он даже не собирается. Отрывайте.


== gcc 10, llvm 12 и сотоварищи ==
== gcc 10, llvm 12 и сотоварищи ==
Строка 23: Строка 32:
== clang/llvm/lld ==
== clang/llvm/lld ==


clang 16.0 и 17.0 не особо поддерживают LSX и LASX (SIMD extensions). Если кто-то их где-то уже пытается применить, отрывайте или переходите на GCC, там оно по крайней мере собирается.
clang 16.0 и 17.0 не особо поддерживают LSX и LASX (SIMD extensions). Если кто-то их где-то уже пытается применить, отрывайте.


LLD (LLVM linker) не поддерживает многих нужных релокаций и пока (as of 17.0) не умеет в релаксации вообще. clang 17 собран так, чтобы по умолчанию использовать ld.bfd (GNU binutils), так что если вы видите ошибку вроде такой:
LLD (LLVM linker) не поддерживает многих нужных релокаций и пока (as of 17.0) не умеет в релаксации вообще. clang 17 собран так, чтобы по умолчанию использовать ld.bfd (GNU binutils), так что если вы видите ошибку вроде такой:
Строка 30: Строка 39:
  clang: error: linker command failed with exit code 1 (use -v to see invocation)
  clang: error: linker command failed with exit code 1 (use -v to see invocation)


то кто-то явно передал clang'у <code>-fuse-ld=lld</code>. Не делайте так и всё соберётся.
то кто-то явно передал clang'у <code>-fuse-ld=lld</code>. Уберите эту опцию и всё соберётся.


== autotools ==
== autotools ==
Строка 38: Строка 47:
  configure: error: cannot guess build type; you must specify one
  configure: error: cannot guess build type; you must specify one


Если в пакете используется <code>%autoreconf</code>, то такой проблемы быть не должно; если нет, лучше сделать чтобы использовался, хотя для этого иногда приходится [https://git.altlinux.org/people/iv/packages/?a=commitdiff;h=b4e8f1e8348b2e9bd16ff7e4d785a80f7d5c914c проявить изобретательность]. Ничего плохого от этого обычно не происходит, а вот хорошее может.
Если в пакете используется <code>%autoreconf</code>, то такой проблемы быть не должно; если нет, лучше сделать чтобы использовался, хотя для этого иногда приходится [https://git.altlinux.org/gears/l/libdb5.3.git?a=commitdiff;h=b4e8f1e8348b2e9bd16ff7e4d785a80f7d5c914c проявить изобретательность]. Ничего плохого от этого обычно не происходит, а вот хорошее может.


Если с <code>%autoreconf</code> ничего не выходит, можно найти в пакете config.guess и config.sub и заменить их на свежие, системные, самым простым способом:
Если с <code>%autoreconf</code> ничего не выходит, можно найти в пакете config.guess и config.sub и заменить их на свежие, системные, самым простым способом:


  cp -f /usr/share/autoconf/build-aux/config.{guess,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!
Приложите патч, [https://git.altlinux.org/gears/e/eclib.git?a=commitdiff;h=91daf705381fc7e58447fd07029900e7663c6e41 например так].


== golang ==
== golang ==


golang на loongarch64 работает. Архитектура в терминах Google называется <code>loong64</code>.
golang на loongarch64 работает. Архитектура в терминах Google называется <code>loong64</code>.
В логах упавшей сборки стоит поискать слово <code>undefined:</code> (примеры ниже).


=== Условная сборка ===
=== Условная сборка ===
Строка 54: Строка 74:
=== Обновление завендоренного ===
=== Обновление завендоренного ===


Пример ошибки:
Часто достаточно обновить завендоренный код до чуть более нового выпуска, в котором поддержка loongarch64 уже добавлена. Просто взять последнюю получается не всегда, так как для этого, например, пришось бы поднять требуемую версию go в проекте, что не всегда хорошо. Приходится искать что-то, что уже поддерживает loong64, но ещё не требует свежести от go.  
 
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 в <code>golang.org/x/sys</code> появилась в 2022 году, более старые версии нужно обновить. Просто взять последнюю получается не всегда, так как для этого надо бы поднимать требуемую версию go в проекте, что не всегда хорошо. Приходится искать что-то, что уже поддерживает loong64, но ещё не требует свежести от go.
'''Если есть <code>go.mod</code>''', то обновить завендоренный модуль можно примерно так:
 
'''Если есть <code>go.mod</code>''':


  go get 'golang.org/x/sys@v0.0.0-20220712014510-0a85c31ab51e'
  go get 'golang.org/x/sys@v0.0.0-20220712014510-0a85c31ab51e'
Строка 81: Строка 95:


'''Если нет <code>go.mod</code>''', импровизируйте.
'''Если нет <code>go.mod</code>''', импровизируйте.
=== 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 в <code>golang.org/x/sys</code> появилась в 2022 году, более старые версии нужно обновить. Мы успешно использовали версию <code>golang.org/x/sys@v0.0.0-20220712014510-0a85c31ab51e</code>
=== github.com/cilium/ebpf ===
Пример ошибки:
  ../../vendor/github.com/cilium/ebpf/internal/vdso.go:64:28: undefined: NativeEndian
<code>github.com/cilium/ebpf</code> получил поддержку loongarch64 в версии 0.11.0, однако в ней немало breaking changes в API, поэтому старые (чаще всего 0.9+) версии луше не обновлять, а приложить тривальный патч, [https://git.altlinux.org/gears/n/nerdctl.git?a=commitdiff;h=7fd11589fa6ba1bc7eb02dbf481a647e97d52a03 например так].
=== 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 ===
Неповторимый оригинал <code>go.etcd.io/bbolt</code>, который был заброшен и форкнут. В него для поддержки loongarch64 нужно [https://git.altlinux.org/gears/c/consul.git?a=blob;f=.gear/0001-Add-loongarc64-support-for-vendored-github.com-boltd.patch;h=4660c07c8bb8c46de0d0956e94d7b1dcdb369e5b добавить файлик].
=== 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 сейчас у платформы. Новые версии берут её из <code>golang.org/x/sys/cpu</code>, для более старых есть [https://git.altlinux.org/gears/g/gvisor-tap-vsock.git?a=commitdiff;h=0c277128ec18cd010aafad35e675f8c515a21a26 патч].


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


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


   cargo update --precise 0.12.7 -p target-lexicon
   cargo update --precise 0.12.7 -p target-lexicon
Строка 94: Строка 154:
Затем закоммитить и перевендорить зависимости.
Затем закоммитить и перевендорить зависимости.


А можно просто [https://git.altlinux.org/gears/h/hyperfine.git?a=commitdiff;h=e3b575dc4db9be0974cd2400437d3a9898225e75 пропатчить], иногда это проще; надо только не забыть обновить <code>.cargo-checksum.json</code>.
Другой вариант решения проблемы -- приложить патч (примеры ниже). Патчи на многие библиотеки тривиальны и добавляют одну-две строки в понятных местах. Однако для завендоренных зависимостей cargo хранит контрольные суммы файлов, поэтому, помимо применения патчей, нужно поправить соответсвующий <code>.cargo-checksum.json</code>.
 
Можно пересчитать контрольные суммы при помощи [https://packages.altlinux.org/en/sisyphus/srpms/cargo-vendor-checksum/ cargo-vendor-checksum], [https://git.altlinux.org/gears/r/ripgrep.git?a=commitdiff;h=657b67fa61f875e9b0edac09524d26a43c431fab  например так]:
 
%patch3500 -p1
diffstat -p1 -l < %PATCH3500 | sed -re 's@vendor/@@' | xargs cargo-vendor-checksum -f
 
Не забудьте добавить сборочные зависимости на cargo-vendor-checksum и diffstat.
 
Часто проще удалить контрольные суммы файлов, cargo на это не ругается, [https://git.altlinux.org/srpms/a/amberol.git?a=blob;f=amberol.spec;h=9b64544bd63d54f12cbc7a9afe3029760dc8b6bb;hb=0.10.3-alt1.1#l63 примерно так]:
 
# 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 ===
 
Базовая поддержка [https://github.com/nix-rust/nix/pull/2045 появилась] в версии 0.27.0, однако [https://git.altlinux.org/srpms/a/amberol.git?a=blob;f=amberol-0.10.3-alt-vendored-nix-loongarch64-support.patch;h=69f14ee0626d5d74475e1699f9eba74831f68e80 приложить патч] обычно проще.
 
=== target-lexicon ===
 
Нужна версия 0.12.7 или новее.
 
=== rustix ===
 
Поддержка loongarch64 появилась в версии 0.38.5 ([https://github.com/bytecodealliance/rustix/commit/ce0d97e753c4c963acd906b9b98388b0566501a1 ce0d97e75]). Однако может оказаться проще [https://git.altlinux.org/gears/3/389-ds-base.git?a=commitdiff;h=4d3978294e14b99ee5c718205caf5f91520f9b15 приложить патч].
 
=== is-terminal ===
 
Нужна версия 0.4.12. Предыдущие версии тянут за собой "старые" rustix и linux-raw-sys.
 
=== terminal_size ===
 
Требуется 0.3.0, более старые зависят от rustix, который не умеет в LoongArch.
 
== qt5-webengine ==


== qt5-webengine, qt6-webengine ==
Нет и в ближайшее время вряд ли будет. Если в пакете используются rpm-macros-qt5-webengine, всё должно работать само. Если нет, переходите на эти макросы ([https://git.altlinux.org/gears/d/doxygen.git?a=commitdiff;h=7d7199a2b5f8b01edccde61b721722bef973e73e например так]).


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


{{Category navigation|title=LoongArch|category=LoongArch|sortkey=*}}
{{Category navigation|title=LoongArch|category=LoongArch|sortkey=*}}

Текущая версия от 10:20, 26 августа 2024

Stub.png
Данная страница находится в разработке.
Эта страница ещё не закончена. Информация, представленная здесь, может оказаться неполной или неверной.


Здесь описаны замечания и рекомендации по исправлению сборки пакетов Сизифа на 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 собран, пользуйтесь.