Bug 44263 - Лишние зависимости
Summary: Лишние зависимости
Status: CLOSED FIXED
Alias: None
Product: Sisyphus
Classification: Development
Component: llvm17.0 (show other bugs)
Version: unstable
Hardware: all Linux
: P5 normal
Assignee: Arseny Maslennikov
QA Contact: qa-sisyphus
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-11-09 18:11 MSK by Valery Inozemtsev
Modified: 2023-10-05 14:30 MSK (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Valery Inozemtsev 2022-11-09 18:11:05 MSK
$ rpmquery -pR clang13.0-libs-13.0.1-alt3.x86_64.rpm       
libc.so.6(GLIBC_2.3.2)(64bit)  
libc.so.6(GLIBC_2.9)(64bit)  
clang13.0-libs-support = 13.0.1-alt3:sisyphus+298982.600.9.1
llvm13.0-libs = 13.0.1-alt3:sisyphus+298982.600.9.1
rpmlib(PayloadIsXz)

Для libclang.so.13/libclang-cpp.so.13 действительно необходима куча заголовочных файлов и статические библиотеки в виде clang13.0-libs-support прибитых гвоздями в спеке?
Comment 1 Valery Inozemtsev 2022-11-09 18:13:05 MSK
это относится и ко всем остальным (11, 12, 14, 15) clang-libs
Comment 2 Arseny Maslennikov 2022-11-13 23:50:03 MSK
(In reply to Valery Inozemtsev from comment #0)
> $ rpmquery -pR clang13.0-libs-13.0.1-alt3.x86_64.rpm       
> libc.so.6(GLIBC_2.3.2)(64bit)  
> libc.so.6(GLIBC_2.9)(64bit)  
> clang13.0-libs-support = 13.0.1-alt3:sisyphus+298982.600.9.1
> llvm13.0-libs = 13.0.1-alt3:sisyphus+298982.600.9.1
> rpmlib(PayloadIsXz)
> 
> Для libclang.so.13/libclang-cpp.so.13 действительно необходима куча
> заголовочных файлов и статические библиотеки в виде clang13.0-libs-support
> прибитых гвоздями в спеке?

Fun fact: эта куча файлов и в 11.0.1-alt1, например[1], шла в составе clang-libs, просто не было пакета -libs-support отдельного.
[1] https://git.altlinux.org/srpms/l/llvm11.0.git?p=llvm11.0.git;a=blob;f=llvm11.spec;h=659847bc56dab3889c89e5e779a6b5e5a9c08202;hb=8986c2acdc8311f69a43a1661a849a2e12788de8#l368
Comment 3 Arseny Maslennikov 2022-11-13 23:51:35 MSK
(In reply to Valery Inozemtsev from comment #0)
> $ rpmquery -pR clang13.0-libs-13.0.1-alt3.x86_64.rpm       
> libc.so.6(GLIBC_2.3.2)(64bit)  
> libc.so.6(GLIBC_2.9)(64bit)  
> clang13.0-libs-support = 13.0.1-alt3:sisyphus+298982.600.9.1
> llvm13.0-libs = 13.0.1-alt3:sisyphus+298982.600.9.1
> rpmlib(PayloadIsXz)
> 
> Для libclang.so.13/libclang-cpp.so.13 действительно необходима куча
> заголовочных файлов и статические библиотеки в виде clang13.0-libs-support
> прибитых гвоздями в спеке?

Понятно, что без clang-libs-support clang работать не будет. А как же, например, clangd? Ему же не надо ни генерировать llvm-код, ни снижать его до машинного — по крайней мере, когда он жуёт си. Может быть, -libs-support нужен самому шлонгу, или rust-крейту cbindgen какому-нибудь, а ему не нужен?
Проведём эксперимент:
% EDITOR='printf %s\n' gear-edit-spec
hasher-priv/hasher-priv.spec
% nvim hasher-priv/pass.c
>>> :LspInfo
Detected filetype:   c                                 
                                                       
1 client(s) attached to this buffer:                   
                                                       
Client: clangd (id: 1, pid: nil, bufnr: [1])           
 filetypes:       c, cpp, objc, objcpp, cuda           
 autostart:       true                                 
 root directory:  /home/ar/gear/hasher-priv/hasher-priv
 cmd:             clangd                               
>>> :lua vim.diagnostic.setloclist()
<открывается пустой loclist>
>>> :qa!
Что и ожидалось.
Теперь без -libs-support. В другом терминале:
# rpm -e --nodeps clang13.0-libs-support
egrep: warning: egrep is obsolescent; using grep -E
Снова в предыдущем терминале:
% nvim hasher-priv/pass.c
>>> :lua vim.diagnostic.setloclist()
hasher-priv/pass.c|1 col 1 error| Too many errors emitted, stopping now
hasher-priv/pass.c|13 col 10-21 error| In included file: 'stddef.h' file not found
hasher-priv/pass.c|23 col 20-26 error| Unknown type name 'size_t'; did you mean 'ssize_t'? (fix available)
hasher-priv/pass.c|25 col 8-14 error| Unknown type name 'size_t'; did you mean 'ssize_t'? (fix available)
hasher-priv/pass.c|26 col 11-21 error| Use of undeclared identifier 'size_t'
hasher-priv/pass.c|50 col 25-38 error| Use of undeclared identifier 'size_t'
hasher-priv/pass.c|53 col 19-27 error| Use of undeclared identifier 'size_t'
hasher-priv/pass.c|54 col 31-35 error| Implicit conversion changes signedness: 'const ssize_t' (aka 'const long') to 'unsigned long'
hasher-priv/pass.c|72 col 60-66 error| Unknown type name 'size_t'; did you mean 'ssize_t'? (fix available)
hasher-priv/pass.c|74 col 8-14 error| Unknown type name 'size_t'; did you mean 'ssize_t'? (fix available)
hasher-priv/pass.c|75 col 11-21 error| Use of undeclared identifier 'size_t'
hasher-priv/pass.c|121 col 25-38 error| Use of undeclared identifier 'size_t'
hasher-priv/pass.c|137 col 2-8 error| Unknown type name 'size_t'; did you mean 'ssize_t'? (fix available)
hasher-priv/pass.c|137 col 37-45 error| Use of undeclared identifier 'size_t'
>>> :qa!
Отлетели stdint.h, stddef.h, ... А они нужны. Как без них код на си анализировать?

В общем, либо NOTABUG, либо есть какие-то пользователи libclang конкретные, которым мешает.
Comment 4 Arseny Maslennikov 2022-11-14 00:18:44 MSK
(In reply to Arseny Maslennikov from comment #3)
> В общем, либо NOTABUG, либо есть какие-то пользователи libclang конкретные,
> которым мешает.

Кроме хедеров, остаются ещё crt и санитайзеры.
Про санитайзеры, может, стоит и отдельно поговорить... Но с ними невозможно собраться, если не давать линкеру полные пути к ним явно.
Comment 5 Valery Inozemtsev 2022-11-14 08:56:43 MSK
к чему все эти выкладки? понятно же что clang-libs-support нужен для clang, а вот пользователям clang-libs он как собаке пятая нога
Comment 6 Arseny Maslennikov 2022-11-14 16:38:46 MSK
(In reply to Valery Inozemtsev from comment #5)
> к чему все эти выкладки? понятно же что clang-libs-support нужен для clang,
> а вот пользователям clang-libs он как собаке пятая нога

А что за пользователи-то такие, которым не нужны stdint.h? rdb.altlinux.org таких не знает.
Comment 7 Valery Inozemtsev 2022-11-14 16:48:27 MSK
есть такие библиотеки, которым нужен libclang-cpp.so.13, но не нужен clang-13
Comment 8 Arseny Maslennikov 2022-11-14 17:03:24 MSK
(In reply to Valery Inozemtsev from comment #7)
> есть такие библиотеки, которым нужен libclang-cpp.so.13, но не нужен clang-13

А, точно, rdb может не резолвить провайды.
Задал в запросе именно libclang-cpp.so.13.
% curl -X GET \                       
  'https://rdb.altlinux.org/api/dependencies/packages_by_dependency?branch=sisyphus&dp_name=libclang-cpp.so.13&dp_type=require' \
  -H 'accept: application/json' | jq '.packages[].name'

Кроме того, что хочет и -libs-support, выдали:
"libMesaOpenCL"
"qt6-tools"

Окей, теперь верю. Спасибо.
Comment 9 Arseny Maslennikov 2023-10-01 23:22:24 MSK
https://git.altlinux.org/tasks/330734/
Оторвал зависимость на -libs-support, пока что от clang-cpp.
Comment 10 Repository Robot 2023-10-03 01:35:42 MSK
llvm17.0-17.0.1-alt4 -> sisyphus:

 Sat Sep 30 2023 Arseny Maslennikov <arseny@altlinux> 17.0.1-alt4
 - Split libclang-cpp.so into its own package. (Closes: 44263)
 - Split libclang.so into its own package, making clangX-libs a compat package
   which pulls both shared libraries in.
Comment 11 Arseny Maslennikov 2023-10-04 12:30:20 MSK
(In reply to Repository Robot from comment #10)
> llvm17.0-17.0.1-alt4 -> sisyphus:
> 
>  Sat Sep 30 2023 Arseny Maslennikov <arseny@altlinux> 17.0.1-alt4
>  - Split libclang-cpp.so into its own package. (Closes: 44263)
>  - Split libclang.so into its own package, making clangX-libs a compat
> package
>    which pulls both shared libraries in.

Этот релиз, правда, оказался сломанным, потому что clang и clangd не вытягивали явно очевидно нужный им пакет clang-support.

В 17.0.2-alt1 зависимости у clang и clangd исправлены.
17.0.2-alt1
Comment 12 Valery Inozemtsev 2023-10-04 12:39:05 MSK
llvm 17.0 рано выбирать по умолчанию, libMesaOpenGL с ним не собирается
Comment 13 Arseny Maslennikov 2023-10-04 15:10:32 MSK
(In reply to Valery Inozemtsev from comment #12)
> llvm 17.0 рано выбирать по умолчанию, libMesaOpenGL с ним не собирается

https://gitlab.freedesktop.org/mesa/mesa/-/issues/8671
Апстрим llvm17.0 выкинул legacy pass manager, от которого в gallivm и clover что-то пока ещё зависит.

Может, нам будет достаточно наложить на месу следующие патчи?
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22980
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24879
Я на них набрёл по ссылкам из mesa issue 8671.