> из пакета llvm20.1 в пакет llvm21.1 .
Из libomp20.1 в libomp21.1

llvm21.1/llvm-project/openmp
> git grep LIBOMP_VERSION_MAJOR
runtime/CMakeLists.txt:set(LIBOMP_VERSION_MAJOR 5)

Прекратите принимать запрещенные вещества.

(Ответ для 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)
Да, она сбежала.

> Прекратите принимать запрещенные вещества.
Не знаю, о чём вы, но, видимо, у вас есть опыт.

в 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. 
Это блокер.

(Ответ для Anton Farygin на комментарий #4)
> @snowmix - надо разработать тест на такое поведение.
Вот, тут перебежала. https://packages.altlinux.org/ru/tasks/399130/

Удачи с тестами

Пакет собран с нарушением Shared Libs Policy.
Предоставьте, пожалуйста, причину так паковать.

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, но это пакет больше виртуальный.

(Ответ для Konstantin A Lepikhov (L.A. Kostis) на комментарий #8)
> https://packages.altlinux.org/en/tasks/416735/ в данном таске предпринята
> попытка как-то решить ситуацию с "блуждающим" libomp.
Вроде, ок. Только, ждать, когда по всем расползётся.

Спасибо!