55586 2025-08-13 10:45:28 +0300 Библиотеки не соотвествуют shared library policy 2026-04-04 02:20:54 +0300 1 1 4 Development Sisyphus wasmtime unstable x86_64 Linux ASSIGNED P5 normal --- 1 rx1513 kiper kiper lav qa-sisyphus oldest_to_newest 270808 0 rx1513 2025-08-13 10:45:28 +0300 https://www.altlinux.org/Shared_Libs_Policy 270809 1 rx1513 2025-08-13 10:47:07 +0300 Мне также непонятно отсутствие макросов для сборки растовской части. 270811 2 rx1513 2025-08-13 10:55:00 +0300 Можете объяснить как вы собирали этот пакет? 270888 3 kiper 2025-08-14 13:43:26 +0300 (Ответ для Сергей Жидких на комментарий #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. 270908 4 rx1513 2025-08-14 16:21:12 +0300 (Ответ для 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-а и если откажется идти на сотрудничество, то заниматься версионированием самостоятельно. 270914 5 kiper 2025-08-14 17:31:04 +0300 (Ответ для Сергей Жидких на комментарий #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-а и если откажется идти на > сотрудничество, то заниматься версионированием самостоятельно. Так и поступлю. 270915 6 kiper 2025-08-14 17:57:21 +0300 (Ответ для kiper на комментарий #5) > (Ответ для Сергей Жидких на комментарий #4) > > Вы пробовали собирать без RUST_MIN_STACK? > > Да. Насколько я помню, падала сборка на x86. В логах сборки прямым текстом > была рекомендация. > > > Если разработчик явно не указал > > требование к размеру стека при сборке, значит переполнение стека может > > указывать на проблемы с компилятором. Совсем недавно из-за этого некоторые > > пакеты периодически падали при сборке. > > Попробую собрать без RUST_MIN_STACK. По итогу сборки отпишусь сюда. Задача > #392457 Этап сборки прошёл. Ошибки переполнения стека не произошла. Благодарю за информацию! 270917 7 rx1513 2025-08-14 18:02:21 +0300 ﷐[U+1F44D]﷑ 285127 8 lav 2026-04-04 02:20:54 +0300 А чем закончилась сборка? Хотелось бы увидеть более новую версию (39 хотя бы)