From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 Date: Thu, 14 Jan 2021 22:12:38 +0100 From: Konstantin Lepikhov To: devel@lists.altlinux.org Message-ID: <20210114211238.GC189650@lks.home> Mail-Followup-To: devel@lists.altlinux.org References: <20210107205220.GA1094824@lks.home> <20210111160945.GA1739369@lks.home> <20210111214100.GA1776208@lks.home> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operation-System: ALT Sisyphus Sisyphus (unstable) (sisyphus) 5.9.0-lks-wks-alt0.1 User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [devel] [#263468] EPERM (try 14) llvm-common.git=11.0.0-alt2 srpm=llvm11.0-11.0.0-alt2.src.rpm X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2021 21:12:43 -0000 Archived-At: List-Archive: List-Post: 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 в рамках конкретного релиза, а не пересобирать весь тулчейн целиком). У вас есть примеры которые вот так прямо нужны в сизифе? > > > > т.е. планируется собирать раздельные версии 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.