Мне также непонятно отсутствие макросов для сборки растовской части.

Можете объяснить как вы собирали этот пакет?

(Ответ для Сергей Жидких на комментарий #2)
> Можете объяснить как вы собирали этот пакет?

В соответствии с https://www.altlinux.org/RPM/Rust и подсматривая, как данный пакет собирался в других дистрибутивах.

(Ответ для Сергей Жидких на комментарий #1)
> Мне также непонятно отсутствие макросов для сборки растовской части.

Прошу простить мою некомпетентность в данном вопросе как человеку, проходящему join. Будет исправлено в следующей сборке.

(Ответ для Сергей Жидких на комментарий #0)
> https://www.altlinux.org/Shared_Libs_Policy

А вот тема баги чуть сложнее, чем может показаться на первый взгляд. В upstream-е wasmtime уже поднимался issue по поводу soname в 2021 году(https://github.com/bytecodealliance/wasmtime/issues/2996).
На текущий момент, насколько я знаю, проблема не решена(хоть issue и закрыт). В документации нет явного указания, что версия ABI wasmtime-c-api привязана к версии самого wasmtime.
В связи с чем можно сделать вывод, что нет явного версионирования ABI, как и определённых гарантий с версионированием основного проекта в отношение API wasmtime-c-api.

Как возможные варианты решения проблемы:
1. Пинать upstream в новой issue, объясняя плюсы soname и версионирования ABI в wasmtime-c-api во второй раз. Возможно приложив PR.
2. В случае, если issue затухнет во второй раз, взвалить версионирование ABI на человека X, которым могу выступить и я, когда руки дойдут до использования в своём личном проекте.

Но эти решения требуют определённого времени, так что сразу предложу временные варианты решения:
1. Оставить как есть. Но я чувствую, что данный вариант не устроит вас и CMake(https://gitlab.kitware.com/cmake/cmake/-/issues/22307#note_971562).
2. Использовать в качестве soname полную версию пакета. Данный вариант уже собран в тестовой задаче #392354(https://git.altlinux.org/tasks/392354).

Эти два временных варианта - две крайности, которые не решают настоящую проблему, описанную в https://www.altlinux.org/Shared_Libs_Policy.

(Ответ для kiper на комментарий #3)
> (Ответ для Сергей Жидких на комментарий #2)
> > Можете объяснить как вы собирали этот пакет?
> 
> В соответствии с https://www.altlinux.org/RPM/Rust и подсматривая, как
> данный пакет собирался в других дистрибутивах.

Вы пробовали собирать без RUST_MIN_STACK? Если разработчик явно не указал требование к размеру стека при сборке, значит переполнение стека может указывать на проблемы с компилятором. Совсем недавно из-за этого некоторые пакеты периодически падали при сборке.

> (Ответ для Сергей Жидких на комментарий #1)
> > Мне также непонятно отсутствие макросов для сборки растовской части.
> 
> Прошу простить мою некомпетентность в данном вопросе как человеку,
> проходящему join. Будет исправлено в следующей сборке.
> 
Спасибо. Обратите также внимание на используемую лицензию, она имеет дополнительный пункт "LLVM Exceptions to the Apache 2.0 License". Поскольку у нас нет такой лицензии её нужно паковать вместе с пакетом как "Apache-2.0 with LLVM-exception" по названию используемому в cargo.toml. Можете в качестве примера взять https://packages.altlinux.org/ru/sisyphus/srpms/llvm17.0/specfiles/

> (Ответ для Сергей Жидких на комментарий #0)
> > https://www.altlinux.org/Shared_Libs_Policy
> 
> А вот тема баги чуть сложнее, чем может показаться на первый взгляд. В
> upstream-е wasmtime уже поднимался issue по поводу soname в 2021
> году(https://github.com/bytecodealliance/wasmtime/issues/2996).
> На текущий момент, насколько я знаю, проблема не решена(хоть issue и
> закрыт). В документации нет явного указания, что версия ABI wasmtime-c-api
> привязана к версии самого wasmtime.
> В связи с чем можно сделать вывод, что нет явного версионирования ABI, как и
> определённых гарантий с версионированием основного проекта в отношение API
> wasmtime-c-api.
> 
> Как возможные варианты решения проблемы:
> 1. Пинать upstream в новой issue, объясняя плюсы soname и версионирования
> ABI в wasmtime-c-api во второй раз. Возможно приложив PR.
> 2. В случае, если issue затухнет во второй раз, взвалить версионирование ABI
> на человека X, которым могу выступить и я, когда руки дойдут до
> использования в своём личном проекте.
> 
> Но эти решения требуют определённого времени, так что сразу предложу
> временные варианты решения:
> 1. Оставить как есть. Но я чувствую, что данный вариант не устроит вас и
> CMake(https://gitlab.kitware.com/cmake/cmake/-/issues/22307#note_971562).
> 2. Использовать в качестве soname полную версию пакета. Данный вариант уже
> собран в тестовой задаче #392354(https://git.altlinux.org/tasks/392354).
> 
> Эти два временных варианта - две крайности, которые не решают настоящую
> проблему, описанную в https://www.altlinux.org/Shared_Libs_Policy.
Спасибо за развёрнутый ответ, было очень полезно узнать про проблемы растовских C-подобных библиотек. Очень плохо что upstream не понимает назначение soname.

Оба временных решения являются плохими. Если разработчики не понимают для чего нужен soname, значит и гарантий что будет однозначное соответствие между C API и версией пакета нет. В таком случае ручное задание soname будет надёжнее.

Я считаю стоит всё-таки достучаться до upstream-а и если откажется идти на сотрудничество, то заниматься версионированием самостоятельно.

(Ответ для Сергей Жидких на комментарий #4)
> Вы пробовали собирать без RUST_MIN_STACK? 

Да. Насколько я помню, падала сборка на x86. В логах сборки прямым текстом была рекомендация.

> Если разработчик явно не указал
> требование к размеру стека при сборке, значит переполнение стека может
> указывать на проблемы с компилятором. Совсем недавно из-за этого некоторые
> пакеты периодически падали при сборке.

Попробую собрать без RUST_MIN_STACK. По итогу сборки отпишусь сюда. Задача #392457

> Спасибо. Обратите также внимание на используемую лицензию, она имеет
> дополнительный пункт "LLVM Exceptions to the Apache 2.0 License". Поскольку
> у нас нет такой лицензии её нужно паковать вместе с пакетом как "Apache-2.0
> with LLVM-exception" по названию используемому в cargo.toml. Можете в
> качестве примера взять
> https://packages.altlinux.org/ru/sisyphus/srpms/llvm17.0/specfiles/

Благодарю. Возьму на заметку и исправлю!


> Оба временных решения являются плохими. Если разработчики не понимают для
> чего нужен soname, значит и гарантий что будет однозначное соответствие
> между C API и версией пакета нет. В таком случае ручное задание soname будет
> надёжнее.

Согласен с вами.

> Я считаю стоит всё-таки достучаться до upstream-а и если откажется идти на
> сотрудничество, то заниматься версионированием самостоятельно.

Так и поступлю.

(Ответ для kiper на комментарий #5)
> (Ответ для Сергей Жидких на комментарий #4)
> > Вы пробовали собирать без RUST_MIN_STACK? 
> 
> Да. Насколько я помню, падала сборка на x86. В логах сборки прямым текстом
> была рекомендация.
> 
> > Если разработчик явно не указал
> > требование к размеру стека при сборке, значит переполнение стека может
> > указывать на проблемы с компилятором. Совсем недавно из-за этого некоторые
> > пакеты периодически падали при сборке.
> 
> Попробую собрать без RUST_MIN_STACK. По итогу сборки отпишусь сюда. Задача
> #392457

Этап сборки прошёл. Ошибки переполнения стека не произошла. 
Благодарю за информацию!

﷐[U+1F44D]﷑

А чем закончилась сборка?
Хотелось бы увидеть более новую версию (39 хотя бы)

Переработку из ветки people/kiper/packages/wasmtime (SONAME, подпакеты common и docs, ExcludeArch %ix86) перенёс в обновление 49.0.3-alt1, таск #437259.

Библиотека теперь libwasmtime.so.49 (только мажорная версия: патч-выпуски wasmtime совместимы), пакет libwasmtime49 с Obsoletes старого libwasmtime. Спасибо за подготовленную работу. Задачу #392457 (43.0.1) можно удалить.

wasmtime-49.0.3-alt1 -> sisyphus:

Fri Oct 16 2026 Vitaly Lipatov <lav@altlinux.ru> 49.0.3-alt1
- new version 49.0.3
- exclude i586 build (rustc runs out of memory on 32-bit)
- build libwasmtime with SONAME libwasmtime.so.49 and package it as libwasmtime49
  according to Shared Libs Policy (closes: #55586)
- add common (license) and docs subpackages, make examples noarch
- use Rust macros (added BuildRequires: rpm-macros-rust),
  fix License (Apache-2.0 with LLVM-exception)
- added BuildRequires: gcc-c++ (cpp.req for the C++ API headers)
- package C API headers in libwasmtime-devel (only conf.h was packaged)
- based on the work of Korney Gedert (thanks to kiper@)
- security fixes:
  + CVE-2026-34941, GHSA-hx6p-xpx3-jvvv: fix heap OOB read in UTF-16 to latin1+utf16 string transcoding.
  + CVE-2026-34942, GHSA-jxhv-7h78-9775: fix panic when transcoding misaligned utf-16 strings.
  + CVE-2026-34943, GHSA-m758-wjhj-p3jq: fix panic when lifting flags component value.
  + CVE-2026-34944, GHSA-qqfj-4vcm-26hv: fix segfault or out-of-sandbox load with f64x2.splat on x86-64.
  + CVE-2026-34945, GHSA-m9w2-8782-2946: fix host data leakage with 64-bit tables and Winch.
  + CVE-2026-34946, GHSA-q49f-xg75-m9xw: fix host panic when Winch executes table.fill.
  + CVE-2026-34971, GHSA-jhxm-h53p-jm7w: fix miscompiled guest heap access (sandbox escape) on aarch64 Cranelift.
  + CVE-2026-34983, GHSA-hfr4-7c6c-48w2: fix use-after-free after cloning wasmtime::Linker.
  + CVE-2026-34987, GHSA-xx5w-cvp6-jv83: fix sandbox-escaping memory access with Winch on aarch64.
  + CVE-2026-34988, GHSA-6wgr-89rj-399p: fix data leakage between pooling allocator instances.
  + CVE-2026-35186, GHSA-f984-pcp8-v2p7: fix improperly masked table.grow return value with Winch.
  + CVE-2026-35195, GHSA-394w-hwhg-8vgm: fix out-of-bounds write or crash when transcoding component model strings.
  + CVE-2026-44216, GHSA-p8xm-42r7-89xg: fix panic when allocating a table exceeding host address space.
  + GHSA-32h6-97mm-8q3c: fix stack buffer overflow from unvalidated async-lifted callback result count.
  + GHSA-hgjw-h833-99q9: fix stores mixing up type indices between engines.
  + GHSA-jqpg-j7w6-42pr: fix dynamic record lifting allocating beyond hostcall fuel limit.
  + GHSA-q554-3cjc-rx7p: fix component-model handle tables not charged to any limit.
  + GHSA-vcg5-q8m5-8379: fix async-entrypoint requirement enforcement.
  + GHSA-vqjp-4c8c-hfgg: fix filesystem sandbox escape via trailing slashes in paths or symlinks.
  + GHSA-wjc8-633q-pwxr: fix stack overflow dropping a long chain of recursive types.