ALT Linux Bugzilla – Full Text Bug Listing
| Summary: | Предложения по улучшению упаковки cmake-конфигов llvm11.0 | ||
|---|---|---|---|
| Product: | Sisyphus | Reporter: | Aleksei Nikiforov <darktemplaralt> |
| Component: | llvm11.0 | Assignee: | Konstantin A Lepikhov (L.A. Kostis) <lakostis> |
| Status: | CLOSED FIXED | QA Contact: | qa-sisyphus |
| Severity: | enhancement | ||
| Priority: | P5 | CC: | lakostis, lav |
| Version: | unstable | ||
| Hardware: | all | ||
| OS: | Linux | ||
Посмотрел ещё возникающие проблемы. Нужна зависимость у clang11.0-devel-static на clangd11.0. Гм. Неужели CMake-конфиги вообще не умеют линковать своих пользователей с динамическими библиотеками? Ещё на ум приходит положить все cmake-конфиги в пакет -devel-cmake, и пусть он провайдит соответственно cmake(LLVM) и cmake(Clang) и имеет зависимости на то, что надо. (In reply to Aleksei Nikiforov from comment #0) > 3) Добавить в clang11.0-devel-static зависимость на clang11.0-tools. > > В конфигах cmake для clang также в качестве целей указана утилита > clang-format и другие утилиты из состава clang11.0-tools. При её отсутствии > при сборке с помощью cmake получается та же ошибка, что и в двух случаях > выше. > Видимо, они вообще всё тянут... (Ответ для Arseny Maslennikov на комментарий #2) > Гм. > > Неужели CMake-конфиги вообще не умеют линковать своих пользователей с > динамическими библиотеками? > > Ещё на ум приходит положить все cmake-конфиги в пакет -devel-cmake, и пусть > он провайдит соответственно cmake(LLVM) и cmake(Clang) и имеет зависимости > на то, что надо. > В любом виде пойдёт, главное чтобы пакеты, содержащие конфиги cmake, имели зависимости на все цели сборки, которые в этих конфигах cmake указаны. > > Видимо, они вообще всё тянут... Да, судя по всему сгенерированные для clang конфиги cmake указывают все цели сборки (приложения и библиотеки, за исключением скриптов) в файле /usr/lib/llvm-11.0/lib64/cmake/clang/ClangTargets-release.cmake, а в файле /usr/lib/llvm-11.0/lib64/cmake/clang/ClangTargets.cmake проверяется их наличие. Аналогично для llvm с файлами /usr/lib/llvm-11.0/lib64/cmake/llvm/LLVMExports-release.cmake и /usr/lib/llvm-11.0/lib64/cmake/llvm/LLVMExports.cmake. Для 32-битных архитектур указанные пути будут отличаться. (In reply to Aleksei Nikiforov from comment #0) > 3) Добавить в clang11.0-devel-static зависимость на clang11.0-tools. > > В конфигах cmake для clang также в качестве целей указана утилита > clang-format и другие утилиты из состава clang11.0-tools. При её отсутствии > при сборке с помощью cmake получается та же ошибка, что и в двух случаях > выше. > > > > Все эти проблемы можно воспроизвести на сборке, например, пакета castxml. (In reply to Aleksei Nikiforov from comment #1) > Посмотрел ещё возникающие проблемы. > > Нужна зависимость у clang11.0-devel-static на clangd11.0. Вот эти вопросы предлагаю обсуждать в bug 39734. > Обоснование следующее: в конфигах cmake в targets указаны и статические библиотеки из llvm11.0-devel-static.
У меня есть подозрение, что в devel-static попали и статические библиотеки, нужные для линковки, и статические аналоги динамических библиотек.
Надеюсь, у нас есть чёткое понимание, что в devel-static размещаются не все статические библиотеки, а только те, которые нужны странным людям, которые хотят собраться без лишних зависимостей.
Или я совсем не понял, что происходит? clang стремиться стать похожим на golang?
Если библиотеки в devel-static не являются альтернативным вариантом, то их просто надо перенести в devel-пакет. Чтобы соблюсти правило: devel-static — для тех, кто захотел собраться статически.
Начиная с мажорной ветки 13 апстрим окончательно сломал упаковку -devel-static. Как я понимаю, этот багрепорт неактуален в поставленном виде, но его есть смысл перепрофилировать на более общую формулировку проблемы: сборка ряда подпроектов из одних исходников в одном пакете формирует (LLVMExports|*Targets).cmake, требующий все собранные компоненты. Сегодня, например, видим вот такие чудесные явления: https://git.altlinux.org/beehive/logs/Sisyphus-x86_64/archive/2022/0413/error/qt6-tools-6.2.2-alt1 Мне кажется, это проблема вообще не llvm, а как работает cmake. Т.к. недавно похожую проблему выловил с libjpeg-turbo, где в cmake targets была ссылка на статическую библиотеку, которой не было в пакете (точнее, ее вообще не было, т.к. ее удалили при сборке), но target был указан при конфигурации. cmake повел себя очень ответственно - сказали собрать статику, значит статика будет везде, даже если мы ее потом не используем (иначе зачем указывали?) |
Прошу внести следующие изменения в упаковку и зависимости пакетов, собираемых из llvm11.0: 1) Перенести сгенерированные конфиги из llvm11.0-devel в llvm11.0-devel-static. Обоснование следующее: в конфигах cmake в targets указаны и статические библиотеки из llvm11.0-devel-static. Из-за этого при использовании cmake в качестве сборочной системы, требуется всегда и llvm11.0-devel, и llvm11.0-devel-static, иначе cmake выходит с ошибкой, что не все цели, указанные в конфиге cmake были найдены. Логичнее, если используется cmake для сборки, сразу в качестве зависимости указывать llvm{,11.0}-devel-static, поскольку без этого пакета всё равно не получится собрать с использованием cmake. Если для сборки используется не cmake, то где лежат конфиги cmake - всё равно. 2) Перенести сгенерированные конфиги из clang11.0-devel в clang11.0-devel-static. Ситуация и аргументация аналогична предыдущей. 3) Добавить в clang11.0-devel-static зависимость на clang11.0-tools. В конфигах cmake для clang также в качестве целей указана утилита clang-format и другие утилиты из состава clang11.0-tools. При её отсутствии при сборке с помощью cmake получается та же ошибка, что и в двух случаях выше. Все эти проблемы можно воспроизвести на сборке, например, пакета castxml.