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

[Paul Wolneykien]

В 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
статикой.

  Кстати, нам бы наверное неплохо было бы завести ThirdPartyLibsPolicy.

>   Замечания, предложения?