Re: [devel] [#263468] EPERM (try 14) llvm-common.git=11.0.0-alt2 srpm=llvm11.0-11.0.0-alt2.src.rpm

[Konstantin Lepikhov <lakostis@altlinux.org>]

Hi Arseny!

On 01/12/2021, at 03:09:01 PM you wrote:

<skip>
> > а мы куда то спешим?
> 
> Самая важная причина, по которой я начал миграцию llvm в собственный
> префикс — в том, что разным пакетам, в т. ч. пакетам-тулчейнам, требуются
> llvm разной мажорной версии в одном репозитории, потому что они написаны
> с расчётом на конкретную мажорную версию, и в том, что пользователи
> не-мейнтейнеры хотели бы иметь в репозитории свежий clang и иногда
> старый clang. Я не планирую сборку rc в репозиторий, но вот test-only
> задания — почему нет, если так будет удобно.
пакеты-тучейны это интересно звучит, но как это применимо к дистрибутиву?
Весь эти тулчейны как правило имеют свой бранч/репо llvm, и живут своей
жизнью, отдельной от апстрима. Т.е. например, они внезапно могут не
поддерживать ту или иную версию gcc/libc в сизифе, я уж не говорю про
архитектуру. И толк-то какой от них? Разве ООО захочет просертифицировать
какой-то продукт на базе этих тулчейнов или нужно будет добиться ABI
совместимости (хотя в этом случае достаточно пропатчить glibc в рамках
конкретного релиза, а не пересобирать весь тулчейн целиком).

У вас есть примеры которые вот так прямо нужны в сизифе?

<skip>
> > > > т.е. планируется собирать раздельные версии clang/llvm/lld?
> 
> на всякий случай уточню: я понял эти слова так, что в репозитории могут
> сосуществовать clang-11, clang-12 и clang-10, lld-11, lld-12 и lld-10, и
> да, разные мажорные версии собираются не из одного исходного пакета.
понял.

> 
> > > 
> > > не в рамках одного исходного пакета.
> > Я знаю, что в Fedora/Arch так делают, поэтому и спросил. Еще у нас есть
> > lav@ который собирает все что находит - 
> > 
> > https://bugzilla.altlinux.org/show_bug.cgi?id=33411
> > https://bugzilla.altlinux.org/show_bug.cgi?id=34672
> > 
> > Тут все еще есть нерешенная проблема - чего мы хотим достигнуть с llvm в
> > сизифе? Конкурентный toolchain или еще одну библиотеку для сборки пакета
> > xyz.
> 
> И то, и другое.
> И не только тулчейн, там ещё много всего интересного.
см. выше.

Как пример от меня - у нас есть пакет vulkan-amdgpu, это vulkan ICD для
amd, который собирается на базе libllvm из master + патчи от amd + обвязка
к железу. Пакетить это "по уму" просто трата времени, поскольку все это
генерирует на выходе _одну_ библиотеку. Т.е. проще собрать libllvm
статиком и воткнуть его в эту библиотеку. В этом виде ваши усилия как бы
сбоку, поскольку все равно AMD собирает эту библиотеку gcc, и, думаю, даже не
планирует переходить на clang.

А есть, например их toolchain https://github.com/ROCm-Developer-Tools/aomp

> AOMP is a clang/llvm compiler, it also supports GPU offloading with HIP,
> CUDA, and OpenCL.

Some sources to support OpenMP target offload on AMD GPUs have not yet
been merged into the upstream LLVM trunk.

Как ваш патч тут поможет?


-- 
WBR et al.