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: > > > > > а мы куда то спешим? > > > > Самая важная причина, по которой я начал миграцию llvm в собственный > > префикс — в том, что разным пакетам, в т. ч. пакетам-тулчейнам, требуются > > llvm разной мажорной версии в одном репозитории, потому что они написаны > > с расчётом на конкретную мажорную версию, и в том, что пользователи > > не-мейнтейнеры хотели бы иметь в репозитории свежий clang и иногда > > старый clang. Я не планирую сборку rc в репозиторий, но вот test-only > > задания — почему нет, если так будет удобно. > пакеты-тучейны это интересно звучит, но как это применимо к дистрибутиву? > Все эти тулчейны как правило имеют свой бранч/репо llvm, и живут своей > жизнью, отдельной от апстрима. Т.е. например, они внезапно могут не Все или не все — покажет практика и время. > поддерживать ту или иную версию gcc/libc в сизифе, я уж не говорю про > архитектуру. И толк-то какой от них? Разве ООО захочет просертифицировать Если официально признАть, что сизиф нужен только в качеСтве базы для дистрибутивов ООО (варианТ покруче — только сертифицированных), то вообще полсизифа надо удалять, а сообщество за пРеделами ООО и его клиентов — распускАть за ненадобностью. > какой-то продукт на базе этих тулчейнов или нужно будет добиться ABI > совместимости (хотя в этом случае достаточно пропатчить glibc в рамках > конкретного релиза, а не пересобирать весь тулчейн целиком). > > У вас есть примеры которые вот так прямо нужны в сизифе? Взглянул вот на сегодняшний rust. 2 патча, не связанные с llvm по смыслу, и 1 патч, принятый в апстрим Rust. %def_without bundled_llvm. Никакой личной жизни не видно, хотя когда-то, скорее всего, была. Впрочем, найдутся и те, кому ничего в сизифе вот так прямо не нужно, потому что их сам сизиф по тем или иным причинам не устраивает, или потому что от всего сизифа им нужно пакетов 50. Более того, у разных лиц это окажутся разные множества пакетов. > > > > > > > т.е. планируется собирать раздельные версии 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.