57054 2025-11-28 10:05:19 +0300 SONAME убежал в другой пакет 2026-05-15 10:17:31 +0300 1 1 4 Development Sisyphus libomp21.1 unstable x86_64 Linux CLOSED FIXED https://bugzilla.altlinux.org/show_bug.cgi?id=56992 P5 normal --- 28944 1 zerg lakostis arseny iv lakostis rider snowmix qa-sisyphus oldest_to_newest 278057 0 zerg 2025-11-28 10:05:19 +0300 SONAME libomp.so.5 убежал из пакета llvm20.1 в пакет llvm21.1 . 278065 1 zerg 2025-11-28 10:16:00 +0300 > из пакета llvm20.1 в пакет llvm21.1 . Из libomp20.1 в libomp21.1 278071 2 lakostis 2025-11-28 10:51:09 +0300 llvm21.1/llvm-project/openmp > git grep LIBOMP_VERSION_MAJOR runtime/CMakeLists.txt:set(LIBOMP_VERSION_MAJOR 5) Прекратите принимать запрещенные вещества. 278088 3 zerg 2025-11-28 13:28:43 +0300 (Ответ для Konstantin A Lepikhov (L.A. Kostis) на комментарий #2) > llvm21.1/llvm-project/openmp > > git grep LIBOMP_VERSION_MAJOR > runtime/CMakeLists.txt:set(LIBOMP_VERSION_MAJOR 5) Да, она сбежала. > Прекратите принимать запрещенные вещества. Не знаю, о чём вы, но, видимо, у вас есть опыт. 278100 4 rider 2025-11-28 14:09:29 +0300 в p10 это в одном пакете https://packages.altlinux.org/ru/p10/files/?q=%2Fusr%2Flib64%2Flibomp.so.5 А в Sisyphus и p11 в другом: https://packages.altlinux.org/ru/p11/files/?q=%2Fusr%2Flib64%2Flibomp.so.5 @snowmix - надо разработать тест на такое поведение. Библиотека не должна переезжать в другой пакет без смены soname. Это блокер. 278104 5 zerg 2025-11-28 14:23:50 +0300 (Ответ для Anton Farygin на комментарий #4) > @snowmix - надо разработать тест на такое поведение. Вот, тут перебежала. https://packages.altlinux.org/ru/tasks/399130/ 278145 6 lakostis 2025-11-28 17:51:24 +0300 Удачи с тестами 278200 7 zerg 2025-12-01 10:35:21 +0300 Пакет собран с нарушением Shared Libs Policy. Предоставьте, пожалуйста, причину так паковать. 286734 8 lakostis 2026-05-03 09:12:09 +0300 https://packages.altlinux.org/en/tasks/416735/ в данном таске предпринята попытка как-то решить ситуацию с "блуждающим" libomp. В апстриме как таковой проблемы нет - там libomp пакуется как часть llvm и какой у него там soname апстриму все равно. Более того, сам код libomp внутри проекта не меняется, а меняются только плагины и "обвязки" вокруг" libomp. Я попробовал взять что у нас уже есть из наработок по содержанию "зоопарка" компиляторов, т.е. идея из libgomp и метод сборки llvm, который предложил Арсений (через префикс и wrapper сслыки в _bindir/ и cmake) К сожалению, полностью применить подход из libgomp не совсем получилось - т.к. у нас gcc "по умолчанию" всегда последней версии, а llvm "по умолчанию" всегда отстает на одну версию от последней доступной. Ну что получилось, работает хорошо: - libomp.so.5 на уровне системной библиотеки предоставляется последней версией llvm - libomp<llvm_ver>-devel у каждой версии свой, но сам libomp.so там является ссылкой на системный libomp.so.5. - libomptarget (вместе с offload) вынесены в отдельный пакет libomptarget<llvm_ver>. - offload и gpu libc являются частью пакета libomp<llvm_ver>-devel, их можно вынести в отдельные пакеты тоже (при желании). В результате openmp можно включить практически у всех llvm'ов (меньше приседаний внутри .spec) и в случае обновления llvm пересобирать зависимые от libomp.so.5 уже не придется (благо внутри libomp.so. версионность присутствует). Ну и вытянется при обновлении разве новый llvm<llvm_ver>-filesystem, но это пакет больше виртуальный. 286749 9 zerg 2026-05-04 09:57:16 +0300 (Ответ для Konstantin A Lepikhov (L.A. Kostis) на комментарий #8) > https://packages.altlinux.org/en/tasks/416735/ в данном таске предпринята > попытка как-то решить ситуацию с "блуждающим" libomp. Вроде, ок. Только, ждать, когда по всем расползётся. 287532 10 zerg 2026-05-15 10:17:31 +0300 Спасибо!