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

Пт Янв 15 11:50:10 MSK 2021

On Thu, Jan 14, 2021 at 10:12:38PM +0100, Konstantin Lepikhov wrote:
> 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 в рамках
> конкретного релиза, а не пересобирать весь тулчейн целиком).
> 
> У вас есть примеры которые вот так прямо нужны в сизифе?

Взглянул вот на сегодняшний rust.
2 патча, не связанные с llvm по смыслу, и 1 патч, принятый в апстрим
Rust. %def_without bundled_llvm. Никакой личной жизни не видно, хотя
когда-то, скорее всего, была.

Впрочем, найдутся и те, кому ничего в сизифе вот так прямо не нужно,
потому что их сам сизиф по тем или иным причинам не устраивает, или
потому что от всего сизифа им нужно пакетов 50. Более того, у разных лиц
это окажутся разные множества пакетов.

> 
> <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.

Можно, конечно, к каждому пользователю llvm в комплект тащить свою копию
llvm (или форк) и собирать его статически, обмазав LTO. Но возникают три
недостатка:
* в репозитории отсутствуют clang и clang-tools для пользователей
  сизифа;
* пакеты будут безобразно распухать в объёме;
* (теор.) в случае необходимости навязать важное исправление патч
  придётся накладывать в N мест вместо 1.

Да, третий пункт — теоретический, но никакой процесс обеспечения
безопасности не имеет смысла, если не опирается на достаточно надёжный
toolchain.
Поэтому у нас и введено в традицию по возможности переиспользовать
компоненты, которые используем при сборке.[1]

По моему личному мнению, первого уже достаточно, чтобы не делать это
"нормой всеобщего законодательства" (c).

> > 
> > И то, и другое.
> > И не только тулчейн, там ещё много всего интересного.
> см. выше.
> 
> Как пример от меня - у нас есть пакет 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.
> 
> Как ваш патч тут поможет?

Тут — честно, никак.

А вот с https://bugzilla.altlinux.org/show_bug.cgi?id=39087 должен
помочь.

P.S.
[1] Даже если целесообразность динамической линковки резко упадёт, есть
теоретические меры, которые можно было бы принять в репозитории —
например, введение в пакетную систему аналога дебиановского Built-Using.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : signature.asc
Тип     : application/pgp-signature
Размер  : 833 байтов
Описание: отсутствует
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20210115/ab023bdb/attachment-0001.bin>