Re: [devel] Обновление protobuf

[Paul Wolneykien <manowar@altlinux.org>]

В Wed, 26 Feb 2025 13:24:13 +0300
Paul Wolneykien <manowar@altlinux.org> пишет:

> В Wed, 26 Feb 2025 09:05:49 +0300
> Paul Wolneykien <manowar@altlinux.org> пишет:
> 
> > В Fri, 21 Feb 2025 23:56:25 +0300
> > Paul Wolneykien <manowar@altlinux.org> пишет:
> >   
> > > В Fri, 21 Feb 2025 22:13:55 +0300
> > > скрылевъ малъ <majioa@yandex.ru> пишет:
> > >     
> > > >  
> > > >  
> > > > ----------------
> > > > Кому: devel@lists.altlinux.org (devel@lists.altlinux.org);
> > > > Тема: [devel] Обновление protobuf;
> > > > 21.02.2025, 12:44, "Anton Farygin" <rider@basealt.ru>:
> > > >       
> > > > > On 20.02.2025 19:37, Paul Wolneykien wrote:    За прошедшее время я несколько раз перезапускал задание по причине      
> > > > >>  нового libabseil и ещё некоторых сложностей. Сегодня удалось обновить
> > > > >>  и запатчить fcitx5-mozc. Других существенных изменений не произошло.      
> > > > > 
> > > > > 
> > > > > Непонятно что делать с grpc      
> > > > А что съ нимъ дѣлать? Я его обновлять хотѣлъ, только для него 29й нуженъ protobuf....      
> > > 
> > >   Не, у меня с 25 собрался (3.25.5) с минорными послаблениями. Но тут
> > > ещё один товарищ вызвался в рассылке, поэтому я пока уступил.
> > > 
> > >   Вот, почти рабочий вариант (собирается с заданием, если сделать
> > > -Wno-error=return-type):    
> > 
> >   Всем привет. В новой итерации задания собран grpc и вместе с ним
> > собран arrow --- то есть grpc выглядит рабочим.
> > 
> >   Однако сборку пришлось существенным образом поменять. В предыдущей
> > (текущей в Сизифе) версии grpc библиотеки из third-party упакованы
> > прямо в %_libdir, причём соответствующие *.so файлы упакованы в 
> > devel пакет. Выходит, они предлагаются для general use другими
> > пакетами, так что-ли? Это не верно хотя бы потому, что версии
> > этих библиотек привязаны к grpc и не будут в таком виде своевременно
> > обновляться. А ещё для них нет заголовочных файлов.
> > 
> >   Более правильным решением тут была бы статическая линковка всего
> > этого third-party. Но беда в том, что такой опции в готовом виде
> > сборка grpc не предоставляет и поэтому в pkg-config файлах этого
> > пакета жёстко прописаны -lXXX -lYYY со всеми third-party. Поэтому
> > перевод на статику получается неоправдано большим патчем.
> >   Есть и ещё одна причина, по которой я отказался от статической
> > линковки: это так называемый композиционный анализ --- то есть,
> > учёт тех компонентов из которых состоит то или иное ПО. Тут понятно,
> > что в случае динамической линковки прям очевидно (по имени файла),
> > что программа включает в себя тот или иной компонент. А вот когда
> > что-то вкомпилячено статикой, поди ещё выяви это что-то в готовом
> > бинаре.
> > 
> >   Исходя из вышеперечисленного, я принял решение упаковать все
> > third-party в %_libdir/grpc/. Правда для этого пришлось добавить
> > RPATH (ну а как ещё?). В таком виде кто попало эти библиотеки не
> > найдёт. В grpc.pc добавил -L%_libdir/grpc.  
> 
>   Пока что, фокус с RPATH не удался. Точнее, он порождает новые
> RPATH по цепочке для клиентов libgrpc. Попробую собрать third-party
> статикой.

  Ложная тревога. Дело было в clang, в котором, похоже, не включён
as-needed по умолчанию. А рецепты по сборке всего этого гуглового
хозяйства, мягко говоря, изобилуют мусором.

  P. S. А почему --as-needed не включён по умолчанию на уровне ld?