ALT Linux Team development discussions
 help / color / mirror / Atom feed
* [devel] I: lib.req: upgraded "library not found" warnings to errors
@ 2022-02-06 13:41 Dmitry V. Levin
  2022-02-06 22:44 ` Alexey V. Vissarionov
  2022-02-09  3:11 ` Evgeniy Kukhtinov
  0 siblings, 2 replies; 13+ messages in thread
From: Dmitry V. Levin @ 2022-02-06 13:41 UTC (permalink / raw)
  To: ALT Devel discussion list

Hi,

#100 rpm-build 4.0.4.180-alt1 -> 4.0.4.181-alt1
 Sun Feb 06 2022 Dmitry V. Levin <ldv@altlinux> 4.0.4.181-alt1
 - lib.req: upgraded "library not found" warnings to errors:
   these warnings are real packaging errors,
   they also cause further ldd errors down the line.

Это изменение затрагивает нижеперечисленные пакеты:
Source package             Not found
--------------             ---------
LibreOffice                libjawt.so
LibreOffice-still          libjawt.so
TORCS                      libclient.so libconfscreens.so liblearning.so libmusicplayer.so libraceengine.so libracescreens.so librobottools.so libtgf.so libtgfclient.so libtxml.so
android-tools              lib7z.so
ardour                     libardour.so.3 libardouralsautil.so.0 libardourcp.so libaudiographer.so.0 libcanvas.so.0 libevoral.so.0 libgtkmm2ext.so.0 libmidipp.so.4 libpbd.so.4 libptformat.so.0 libtemporal.so.0 libwaveview.so.0 libwidgets.so.0
bacula11                   libbaccats-11.0.5.so
bolzplatz2006              libjawt.so
cadabra2                   cadabra2.cpython-310.so
electron                   libffmpeg.so
electron10                 libffmpeg.so
electron13                 libffmpeg.so
electron14                 libffmpeg.so
electron4                  libGLESv2.so libffmpeg.so
electron8                  libffmpeg.so
electron9                  libffmpeg.so
eog                        libeog.so
eog-plugins                libeog.so
freerdp                    liburbdrc-client.so
gedit                      libgedit-40.0.so
gedit-plugins              libgedit-40.0.so
gnome-software             libgnomesoftware.so.16
java3d                     libjawt.so libjvm.so
jogl                       libjawt.so
jogl2                      libjawt.so
llvm11.0                   liblldb.so.11
llvm12.0                   liblldb.so.12
lmms                       libZynAddSubFxCore.so
mysql-workbench-community  db.mysql.wbp.so.8.0.25 libcdbc.so.8.0.25 libgrt.so.8.0.25 liblinux_utilities.so.8.0.25 libmdcanvas.so.8.0.25 libmdcanvasgtk.so.8.0.25 libmforms.so.8.0.25 libmtemplate.so.8.0.25 libparsers.so.8.0.25 libsqlide.so.8.0.25 libsqlparser.so.8.0.25 libwbbase.so.8.0.25 libwbprivate.so.8.0.25 libwbpublic.so.8.0.25 libwbscintilla.so.4.1.5 libwbssh.so.8.0.25
netxms                     libnxdbmgr-2
nx-libs                    libNX_X11.so.6
ogre                       Codec_STBI.so.13.2 Plugin_PCZSceneManager.so.13.2
ogre19                     Plugin_PCZSceneManager.so.1.9.1
openmodelica               libOMSISolver.so libamd.so libbtf.so libcoinmumps.so.1 libcolamd.so libklu.so libsuitesparseconfig.so libsundials_kinsol.so.5 libsundials_nvecserial.so.5 libsundials_sunmatrixband.so.3 libsundials_sunmatrixdense.so.3 libsundials_sunmatrixsparse.so.3
openssl-engines-rutoken    libcrypto.so.1.1
opentoonz                  libcolorfx.so libimage.so libsound.so libtfarm.so libtnzbase.so libtnzcore.so libtnzext.so libtnzstdfx.so libtnztools.so libtoonzlib.so libtoonzqt.so
purple-xmpp-http-upload    libjabber.so.0
scilab                     libjava.so libjvm.so libverify.so
swi-prolog                 libjvm.so
tracker-miners             libtracker-extract.so
tracker-miners3            libtracker-extract.so
trikStudio                 libBox2D.so.1 libqextserialport.so.1 libqrgraph.so.1 libqrgui-brand-manager.so.1 libqrgui-controller.so.1 libqrgui-dialogs.so.1 libqrgui-editor.so.1 libqrgui-facade.so.1 libqrgui-hotkey-manager.so.1 libqrgui-meta-meta-model.so.1 libqrgui-models.so.1 libqrgui-mouse-gestures.so.1 libqrgui-plugin-manager.so.1 libqrgui-preferences-dialog.so.1 libqrgui-text-editor.so.1 libqrgui-thirdparty.so.1 libqrgui-tool-plugin-interface.so.1 libqrkernel.so.1 libqrrepo.so.1 libqrtext.so.1 libqrutils.so.1 librobots-2d-model.so.1 librobots-ev3-generator-base.so.1 librobots-ev3-kit.so.1 librobots-generator-base.so.1 librobots-interpreter-core.so.1 librobots-kit-base.so.1 librobots-nxt-generator-base.so.1 librobots-nxt-kit.so.1 librobots-pioneer-kit.so.1 librobots-trik-generator-base.so.1 librobots-trik-kit-interpreter-common.so.1 librobots-trik-kit.so.1 librobots-trik-python-generator-library.so.1 librobots-trik-qts-generator-library.so.1 librobots-utils.so.1 libtrikControl.so.1 libtrikHal.so.1 libtrikKernel.so.1 libtrikNetwork.so.1 libtrikPythonQt-Qt515-Python3.10.so.1 libtrikPythonQt_QtAll-Qt515-Python3.10.so.1 libtrikQsLog.so.2 libtrikScriptRunner.so.1
trikStudioJunior           libqrgraph.so.1 libqrgui-brand-manager.so.1 libqrgui-controller.so.1 libqrgui-dialogs.so.1 libqrgui-editor.so.1 libqrgui-facade.so.1 libqrgui-hotkey-manager.so.1 libqrgui-meta-meta-model.so.1 libqrgui-models.so.1 libqrgui-mouse-gestures.so.1 libqrgui-plugin-manager.so.1 libqrgui-preferences-dialog.so.1 libqrgui-text-editor.so.1 libqrgui-thirdparty.so.1 libqrgui-tool-plugin-interface.so.1 libqrkernel.so.1 libqrrepo.so.1 libqrtext.so.1 libqrutils.so.1 libqslog.so.1 librobots-2d-model.so.1 librobots-interpreter-core.so.1 librobots-kit-base.so.1 librobots-trik-kit-interpreter-common.so.1 librobots-trik-kit.so.1 librobots-utils.so.1
tupitube-desk              libjson-c.so.1 libqtmypaint.so.1 librasterbrushes.so.1 librastercolor.so.1 librastermain.so.1 libtupi.so.1 libtupibase.so.1 libtupicolor.so.1 libtupifwcore.so.1 libtupifwgui.so.1 libtupiplugincommon.so.1 libtupistore.so.1
virtualbox                 VBoxRT.so
wine                       ntdll.so
wine-vanilla               ntdll.so


-- 
ldv


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [devel] I: lib.req: upgraded "library not found" warnings to errors
  2022-02-06 13:41 [devel] I: lib.req: upgraded "library not found" warnings to errors Dmitry V. Levin
@ 2022-02-06 22:44 ` Alexey V. Vissarionov
  2022-02-06 23:01   ` Dmitry V. Levin
  2022-02-09  3:11 ` Evgeniy Kukhtinov
  1 sibling, 1 reply; 13+ messages in thread
From: Alexey V. Vissarionov @ 2022-02-06 22:44 UTC (permalink / raw)
  To: ALT Linux Team development discussions

On 2022-02-06 16:41:12 +0300, Dmitry V. Levin wrote:

 > lib.req: upgraded "library not found" warnings to errors:
 > these warnings are real packaging errors, they also cause
 > further ldd errors down the line.
 > Это изменение затрагивает нижеперечисленные пакеты

Дим, а вот тут нужна ручка для отключения: например, лично я
предпочитаю использовать "охвисный" пакет (любителям файлов в
проприетарных форматах особый превед) без Java со всеми ее
ужасающими зависимостями.

То есть, по умолчанию это и должно быть ошибками, но должна
быть возможность сказать "если кто-то не ставит %name-all для
удовлетворения всех зависимостей, то эти люди действительно
знают, что делают".


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [devel] I: lib.req: upgraded "library not found" warnings to errors
  2022-02-06 22:44 ` Alexey V. Vissarionov
@ 2022-02-06 23:01   ` Dmitry V. Levin
  2022-02-07  3:18     ` Alexey V. Vissarionov
                       ` (2 more replies)
  0 siblings, 3 replies; 13+ messages in thread
From: Dmitry V. Levin @ 2022-02-06 23:01 UTC (permalink / raw)
  To: ALT Linux Team development discussions

On Mon, Feb 07, 2022 at 01:44:06AM +0300, Alexey V. Vissarionov wrote:
> On 2022-02-06 16:41:12 +0300, Dmitry V. Levin wrote:
> 
>  > lib.req: upgraded "library not found" warnings to errors:
>  > these warnings are real packaging errors, they also cause
>  > further ldd errors down the line.
>  > Это изменение затрагивает нижеперечисленные пакеты
> 
> Дим, а вот тут нужна ручка для отключения: например, лично я
> предпочитаю использовать "охвисный" пакет (любителям файлов в
> проприетарных форматах особый превед) без Java со всеми ее
> ужасающими зависимостями.

Это всё давно есть.

Тут речь идёт о том, что если некий elf уже слинкован с некоторой
библиотекой, эта библиотека должна быть доступна для lib.req,
иначе lib.req оказывается в сложной ситуации.

А так можно фильтровать и то, что попадает к lib.req, и то,
что получается на выходе.


-- 
ldv


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [devel] I: lib.req: upgraded "library not found" warnings to errors
  2022-02-06 23:01   ` Dmitry V. Levin
@ 2022-02-07  3:18     ` Alexey V. Vissarionov
  2022-02-08 20:50     ` Vitaly Lipatov
  2022-04-28 11:39     ` Sergey Afonin
  2 siblings, 0 replies; 13+ messages in thread
From: Alexey V. Vissarionov @ 2022-02-07  3:18 UTC (permalink / raw)
  To: ALT Linux Team development discussions

On 2022-02-07 02:01:30 +0300, Dmitry V. Levin wrote:

 >>> lib.req: upgraded "library not found" warnings to errors:
 >>> these warnings are real packaging errors, they also cause
 >>> further ldd errors down the line.
 >>> Это изменение затрагивает нижеперечисленные пакеты
 >> Дим, а вот тут нужна ручка для отключения: например, лично я
 >> предпочитаю использовать "охвисный" пакет (любителям файлов в
 >> проприетарных форматах особый превед) без Java со всеми ее
 >> ужасающими зависимостями.
 > Это всё давно есть.

Очхшо.

 > Тут речь идёт о том, что если некий elf уже слинкован с
 > некоторой библиотекой, эта библиотека должна быть доступна
 > для lib.req, иначе lib.req оказывается в сложной ситуации.

И вот тут нужен способ подсказать ему, что же имел в виду
мейнтейнер.

 > А так можно фильтровать и то, что попадает к lib.req, и то,
 > что получается на выходе.

man что?


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [devel] I: lib.req: upgraded "library not found" warnings to errors
  2022-02-06 23:01   ` Dmitry V. Levin
  2022-02-07  3:18     ` Alexey V. Vissarionov
@ 2022-02-08 20:50     ` Vitaly Lipatov
  2022-02-09  0:11       ` Dmitry V. Levin
  2022-04-28 11:39     ` Sergey Afonin
  2 siblings, 1 reply; 13+ messages in thread
From: Vitaly Lipatov @ 2022-02-08 20:50 UTC (permalink / raw)
  To: ALT Linux Team development discussions; +Cc: Dmitry V. Levin

Dmitry V. Levin писал(а) 7.2.22 2:01:
> On Mon, Feb 07, 2022 at 01:44:06AM +0300, Alexey V. Vissarionov wrote:
>> On 2022-02-06 16:41:12 +0300, Dmitry V. Levin wrote:
>> 
>>  > lib.req: upgraded "library not found" warnings to errors:
>>  > these warnings are real packaging errors, they also cause
>>  > further ldd errors down the line.
>>  > Это изменение затрагивает нижеперечисленные пакеты
>> 
>> Дим, а вот тут нужна ручка для отключения: например, лично я
>> предпочитаю использовать "охвисный" пакет (любителям файлов в
>> проприетарных форматах особый превед) без Java со всеми ее
>> ужасающими зависимостями.
> 
> Это всё давно есть.
> 
> Тут речь идёт о том, что если некий elf уже слинкован с некоторой
> библиотекой, эта библиотека должна быть доступна для lib.req,
> иначе lib.req оказывается в сложной ситуации.
> 
> А так можно фильтровать и то, что попадает к lib.req, и то,
> что получается на выходе.

Вы не могли бы подсказать хороший способ для этого?
Вот к примеру
https://git.altlinux.org/tasks/295053/gears/10/git?p=git;a=blob;f=test_lib_requires2.spec;h=93cbd138404bdff484450d986f7b42f0a6721d4f;hb=57d1826fc867f8617bb0de9e0cb3af1c872a3161

у меня есть приватная библиотека ntdll.so, которая расположена в 
%_libdir/%name
Там же находится линкующаяся с ntdll.so библиотека sane.so.

Я смог найти только такой вариант:
1. Положил ntdll.so также и в %_libdir
2. Убрал генерируемые зависимости на неё:
%filter_from_requires /^ntdll.so()(64bit).*/d
3. Не стал упаковывать %_libdir/ntdll.so в пакет, потому что она там не 
нужна.

https://git.altlinux.org/tasks/295053/build/10/x86_64/log

А как было бы лучше? При условии, что мне нужны auto requires для 
ntdll.so, но не нужны auto provides для неё.

-- 
С уважением,
Виталий Липатов,
ALT Linux Team


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [devel] I: lib.req: upgraded "library not found" warnings to errors
  2022-02-08 20:50     ` Vitaly Lipatov
@ 2022-02-09  0:11       ` Dmitry V. Levin
  2022-02-09  0:54         ` Vitaly Lipatov
  0 siblings, 1 reply; 13+ messages in thread
From: Dmitry V. Levin @ 2022-02-09  0:11 UTC (permalink / raw)
  To: ALT Devel discussion list

On Tue, Feb 08, 2022 at 11:50:39PM +0300, Vitaly Lipatov wrote:
> Dmitry V. Levin писал(а) 7.2.22 2:01:
> > On Mon, Feb 07, 2022 at 01:44:06AM +0300, Alexey V. Vissarionov wrote:
> >> On 2022-02-06 16:41:12 +0300, Dmitry V. Levin wrote:
> >> 
> >>  > lib.req: upgraded "library not found" warnings to errors:
> >>  > these warnings are real packaging errors, they also cause
> >>  > further ldd errors down the line.
> >>  > Это изменение затрагивает нижеперечисленные пакеты
> >> 
> >> Дим, а вот тут нужна ручка для отключения: например, лично я
> >> предпочитаю использовать "охвисный" пакет (любителям файлов в
> >> проприетарных форматах особый превед) без Java со всеми ее
> >> ужасающими зависимостями.
> > 
> > Это всё давно есть.
> > 
> > Тут речь идёт о том, что если некий elf уже слинкован с некоторой
> > библиотекой, эта библиотека должна быть доступна для lib.req,
> > иначе lib.req оказывается в сложной ситуации.
> > 
> > А так можно фильтровать и то, что попадает к lib.req, и то,
> > что получается на выходе.
> 
> Вы не могли бы подсказать хороший способ для этого?
> Вот к примеру
> https://git.altlinux.org/tasks/295053/gears/10/git?p=git;a=blob;f=test_lib_requires2.spec;h=93cbd138404bdff484450d986f7b42f0a6721d4f;hb=57d1826fc867f8617bb0de9e0cb3af1c872a3161
> 
> у меня есть приватная библиотека ntdll.so, которая расположена в 
> %_libdir/%name
> Там же находится линкующаяся с ntdll.so библиотека sane.so.

По идее, достаточно сделать %add_findprov_lib_path %_libdir/%name,
плюс что-то у линкующихся, например, rpath или ld.so.conf,
должно навести линкер на мысль поискать библиотеку в %_libdir/%name/.

> Я смог найти только такой вариант:
> 1. Положил ntdll.so также и в %_libdir
> 2. Убрал генерируемые зависимости на неё:
> %filter_from_requires /^ntdll.so()(64bit).*/d
> 3. Не стал упаковывать %_libdir/ntdll.so в пакет, потому что она там не 
> нужна.

Это по сути способ отключить проверку зависимостей на ntdll.so.

> https://git.altlinux.org/tasks/295053/build/10/x86_64/log
> 
> А как было бы лучше? При условии, что мне нужны auto requires для 
> ntdll.so, но не нужны auto provides для неё.

Почему вы хотите избежать auto provides вида
%_libdir/%name/ntdll.so()(64bit) ?


-- 
ldv


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [devel] I: lib.req: upgraded "library not found" warnings to errors
  2022-02-09  0:11       ` Dmitry V. Levin
@ 2022-02-09  0:54         ` Vitaly Lipatov
  0 siblings, 0 replies; 13+ messages in thread
From: Vitaly Lipatov @ 2022-02-09  0:54 UTC (permalink / raw)
  To: ALT Linux Team development discussions; +Cc: Dmitry V. Levin

Dmitry V. Levin писал(а) 9.2.22 3:11:
> On Tue, Feb 08, 2022 at 11:50:39PM +0300, Vitaly Lipatov wrote:
...
>> Вы не могли бы подсказать хороший способ для этого?
>> Вот к примеру
>> https://git.altlinux.org/tasks/295053/gears/10/git?p=git;a=blob;f=test_lib_requires2.spec;h=93cbd138404bdff484450d986f7b42f0a6721d4f;hb=57d1826fc867f8617bb0de9e0cb3af1c872a3161
>> 
>> у меня есть приватная библиотека ntdll.so, которая расположена в
>> %_libdir/%name
>> Там же находится линкующаяся с ntdll.so библиотека sane.so.
> 
> По идее, достаточно сделать %add_findprov_lib_path %_libdir/%name,
> плюс что-то у линкующихся, например, rpath или ld.so.conf,
> должно навести линкер на мысль поискать библиотеку в %_libdir/%name/.
Видимо я не хочу наводить линкер на мысль, делать rpath или тем более 
ld.so.conf.
К тому же такое указание приведёт к появлению provides всех библиотек в 
%_libdir/name, а они никому не нужны снаружи.

В Wine придерживаются подхода, что его можно запускать из любого 
каталога, потому там не будет rpath для библиотек. Если его добавлять, 
то надо понимать, за что мы боремся.

>> Я смог найти только такой вариант:
>> 1. Положил ntdll.so также и в %_libdir
>> 2. Убрал генерируемые зависимости на неё:
>> %filter_from_requires /^ntdll.so()(64bit).*/d
>> 3. Не стал упаковывать %_libdir/ntdll.so в пакет, потому что она там 
>> не
>> нужна.
> 
> Это по сути способ отключить проверку зависимостей на ntdll.so.
Да. Но я думал, что есть менее костыльный.

>> https://git.altlinux.org/tasks/295053/build/10/x86_64/log
>> 
>> А как было бы лучше? При условии, что мне нужны auto requires для
>> ntdll.so, но не нужны auto provides для неё.
> 
> Почему вы хотите избежать auto provides вида
> %_libdir/%name/ntdll.so()(64bit) ?
Ну я думал, что начнётся история с дубликатами. Пакетов с ntdll.so 
внутри может быть много, но снаружи об этом незачем знать.
Но видимо, если полный путь, то не начнётся. Просто чтобы не мусорить?

-- 
С уважением,
Виталий Липатов,
ALT Linux Team


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [devel] I: lib.req: upgraded "library not found" warnings to errors
  2022-02-06 13:41 [devel] I: lib.req: upgraded "library not found" warnings to errors Dmitry V. Levin
  2022-02-06 22:44 ` Alexey V. Vissarionov
@ 2022-02-09  3:11 ` Evgeniy Kukhtinov
  2022-02-09 11:15   ` Dmitry V. Levin
  1 sibling, 1 reply; 13+ messages in thread
From: Evgeniy Kukhtinov @ 2022-02-09  3:11 UTC (permalink / raw)
  To: ALT Linux Team development discussions

6 февраля 2022 г. 13:41:12 UTC, "Dmitry V. Levin" <ldv@altlinux.org> пишет:
>Hi,
>
>#100 rpm-build 4.0.4.180-alt1 -> 4.0.4.181-alt1
> Sun Feb 06 2022 Dmitry V. Levin <ldv@altlinux> 4.0.4.181-alt1
> - lib.req: upgraded "library not found" warnings to errors:
>   these warnings are real packaging errors,
>   they also cause further ldd errors down the line.
>
>Это изменение затрагивает нижеперечисленные пакеты:
>Source package             Not found
>--------------             ---------
>LibreOffice                libjawt.so
>LibreOffice-still          libjawt.so
 […]
>
>
>-- 
>ldv
>_______________________________________________
>Devel mailing list
>Devel@lists.altlinux.org
>https://lists.altlinux.org/mailman/listinfo/devel
Доброго времени суток, коллеги!

При пересборке LibreOffice-7.3.0.3-alt1
словил:

[...]
verify-elf: WARNING: ./usr/lib64/LibreOffice/program/libofficebean.so: not found: libjawt.so
[...]
lib.req: ERROR: /usr/src/tmp/LibreOffice-buildroot/usr/lib64/LibreOffice/program/libofficebean.so: library libjawt.so not found
[...]
find-requires: ERROR: /usr/lib/rpm/lib.req failed
error: /bin/sh failed
error: Failed to find Requires


RPM build errors:
    /bin/sh failed
    Failed to find Requires
Command exited with non-zero status 1
29421.00user 2368.58system 1:15:03elapsed 705%CPU (0avgtext+0avgdata 1073108maxresident)k
4537264inputs+44118096outputs 
(7988major+663600961minor)pagefaults 0swaps
hsh-rebuild: rebuild of `pkg.tar' failed

Я так понимаю, это связано с недавним коммитом ldv@:

https://git.altlinux.org/gears/r/rpm-build.git?p=rpm-build.git;a=commitdiff;h=9db3eec288c45141435c38eaa1ea70397e9c373b

Всё бы ничего, полезное нововведение, но вот библиотека в сборочном окружении имеется,
хотя и по нестандартному пути:

[builder@localhost ~]$ find / -name libjawt\*
/usr/lib/jvm/java-11-openjdk-11.0.14.0.1-0.x86_64/lib/libjawt.so

Итог: нужный пакет не пакуется.

ldv@, коллеги, как избежать прерывания упаковки пакета, ведь в данном случае поведение lib.req неуместно?

--
С уважением, Евгений Кухтинов
<neurofreak@altlinux.org>


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [devel] I: lib.req: upgraded "library not found" warnings to errors
  2022-02-09  3:11 ` Evgeniy Kukhtinov
@ 2022-02-09 11:15   ` Dmitry V. Levin
  2022-02-09 12:12     ` Vitaly Lipatov
  0 siblings, 1 reply; 13+ messages in thread
From: Dmitry V. Levin @ 2022-02-09 11:15 UTC (permalink / raw)
  To: devel

On Wed, Feb 09, 2022 at 03:11:32AM +0000, Evgeniy Kukhtinov wrote:
[...]
> Всё бы ничего, полезное нововведение, но вот библиотека в сборочном окружении имеется,
> хотя и по нестандартному пути:
> 
> [builder@localhost ~]$ find / -name libjawt\*
> /usr/lib/jvm/java-11-openjdk-11.0.14.0.1-0.x86_64/lib/libjawt.so
> 
> Итог: нужный пакет не пакуется.
> 
> ldv@, коллеги, как избежать прерывания упаковки пакета, ведь в данном случае поведение lib.req неуместно?

Библиотеки, с которыми слинкованы приложения и библиотеки, должны
находиться.  Надо исправить упаковку, чтобы библиотеки находились.
Возможно, нужно исправить пакет, в котором находится библиотека.
Возможно, нужно исправить пакет, в котором линкуются с библиотекой.
Но так или иначе библиотеки, с которыми линкуются, должны находиться.


-- 
ldv


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [devel] I: lib.req: upgraded "library not found" warnings to errors
  2022-02-09 11:15   ` Dmitry V. Levin
@ 2022-02-09 12:12     ` Vitaly Lipatov
  2022-02-09 12:46       ` Dmitry V. Levin
  0 siblings, 1 reply; 13+ messages in thread
From: Vitaly Lipatov @ 2022-02-09 12:12 UTC (permalink / raw)
  To: ALT Linux Team development discussions

Dmitry V. Levin писал(а) 9.2.22 14:15:
> On Wed, Feb 09, 2022 at 03:11:32AM +0000, Evgeniy Kukhtinov wrote:
> [...]
>> Всё бы ничего, полезное нововведение, но вот библиотека в сборочном 
>> окружении имеется,
>> хотя и по нестандартному пути:
>> 
>> [builder@localhost ~]$ find / -name libjawt\*
>> /usr/lib/jvm/java-11-openjdk-11.0.14.0.1-0.x86_64/lib/libjawt.so
>> 
>> Итог: нужный пакет не пакуется.
>> 
>> ldv@, коллеги, как избежать прерывания упаковки пакета, ведь в данном 
>> случае поведение lib.req неуместно?
> 
> Библиотеки, с которыми слинкованы приложения и библиотеки, должны
> находиться.  Надо исправить упаковку, чтобы библиотеки находились.
> Возможно, нужно исправить пакет, в котором находится библиотека.
> Возможно, нужно исправить пакет, в котором линкуются с библиотекой.
> Но так или иначе библиотеки, с которыми линкуются, должны находиться.
Правильно ли я понимаю, что на самом деле большинство выявленных случаев 
относятся как раз к случаям, когда не нужно было линковаться с такой 
библиотекой, которая больше похожа на плагин?
Ведь раз её всё же находят (эту вот libjawt.so, наверняка там есть и 
механизм подгрузки, а линковка как раз лишняя (ну или полезна только на 
стадии сборки).

-- 
С уважением,
Виталий Липатов,
ALT Linux Team


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [devel] I: lib.req: upgraded "library not found" warnings to errors
  2022-02-09 12:12     ` Vitaly Lipatov
@ 2022-02-09 12:46       ` Dmitry V. Levin
  2022-02-27 13:15         ` Yuri Sedunov
  0 siblings, 1 reply; 13+ messages in thread
From: Dmitry V. Levin @ 2022-02-09 12:46 UTC (permalink / raw)
  To: ALT Devel discussion list

On Wed, Feb 09, 2022 at 03:12:56PM +0300, Vitaly Lipatov wrote:
> Dmitry V. Levin писал(а) 9.2.22 14:15:
> > On Wed, Feb 09, 2022 at 03:11:32AM +0000, Evgeniy Kukhtinov wrote:
> > [...]
> >> Всё бы ничего, полезное нововведение, но вот библиотека в сборочном 
> >> окружении имеется,
> >> хотя и по нестандартному пути:
> >> 
> >> [builder@localhost ~]$ find / -name libjawt\*
> >> /usr/lib/jvm/java-11-openjdk-11.0.14.0.1-0.x86_64/lib/libjawt.so
> >> 
> >> Итог: нужный пакет не пакуется.
> >> 
> >> ldv@, коллеги, как избежать прерывания упаковки пакета, ведь в данном 
> >> случае поведение lib.req неуместно?
> > 
> > Библиотеки, с которыми слинкованы приложения и библиотеки, должны
> > находиться.  Надо исправить упаковку, чтобы библиотеки находились.
> > Возможно, нужно исправить пакет, в котором находится библиотека.
> > Возможно, нужно исправить пакет, в котором линкуются с библиотекой.
> > Но так или иначе библиотеки, с которыми линкуются, должны находиться.
> Правильно ли я понимаю, что на самом деле большинство выявленных случаев 
> относятся как раз к случаям, когда не нужно было линковаться с такой 
> библиотекой, которая больше похожа на плагин?
> Ведь раз её всё же находят (эту вот libjawt.so, наверняка там есть и 
> механизм подгрузки, а линковка как раз лишняя (ну или полезна только на 
> стадии сборки).

По логу сборки сложно сделать достоверный вывод о том, используется ли
библиотека как плагин.  Может быть, слинкованное приложение падает, если
при запуске библиотека не находится.  А может быть, библиотека всегда
находится по каким-то другим причинам.


-- 
ldv


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [devel] I: lib.req: upgraded "library not found" warnings to errors
  2022-02-09 12:46       ` Dmitry V. Levin
@ 2022-02-27 13:15         ` Yuri Sedunov
  0 siblings, 0 replies; 13+ messages in thread
From: Yuri Sedunov @ 2022-02-27 13:15 UTC (permalink / raw)
  To: devel

В Ср, 09/02/2022 в 15:46 +0300, Dmitry V. Levin пишет:
> On Wed, Feb 09, 2022 at 03:12:56PM +0300, Vitaly Lipatov wrote:
> > Dmitry V. Levin писал(а) 9.2.22 14:15:
> > > On Wed, Feb 09, 2022 at 03:11:32AM +0000, Evgeniy Kukhtinov
> > > wrote:
> > > [...]
> > > > Всё бы ничего, полезное нововведение, но вот библиотека в
> > > > сборочном 
> > > > окружении имеется,
> > > > хотя и по нестандартному пути:
> > > > 
> > > > [builder@localhost ~]$ find / -name libjawt\*
> > > > /usr/lib/jvm/java-11-openjdk-11.0.14.0.1-
> > > > 0.x86_64/lib/libjawt.so
> > > > 
> > > > Итог: нужный пакет не пакуется.
> > > > 
> > > > ldv@, коллеги, как избежать прерывания упаковки пакета, ведь в
> > > > данном 
> > > > случае поведение lib.req неуместно?
> > > 
> > > Библиотеки, с которыми слинкованы приложения и библиотеки, должны
> > > находиться.  Надо исправить упаковку, чтобы библиотеки
> > > находились.
> > > Возможно, нужно исправить пакет, в котором находится библиотека.
> > > Возможно, нужно исправить пакет, в котором линкуются с
> > > библиотекой.
> > > Но так или иначе библиотеки, с которыми линкуются, должны
> > > находиться.
> > Правильно ли я понимаю, что на самом деле большинство выявленных
> > случаев 
> > относятся как раз к случаям, когда не нужно было линковаться с
> > такой 
> > библиотекой, которая больше похожа на плагин?
> > Ведь раз её всё же находят (эту вот libjawt.so, наверняка там есть
> > и 
> > механизм подгрузки, а линковка как раз лишняя (ну или полезна
> > только на 
> > стадии сборки).
> 
> По логу сборки сложно сделать достоверный вывод о том, используется
> ли
> библиотека как плагин.  Может быть, слинкованное приложение падает,
> если
> при запуске библиотека не находится.  А может быть, библиотека всегда
> находится по каким-то другим причинам.
> 

Если указания  %add_findprov_lib_path недостаточно, то что делать?

-- 
Yuri N. Sedunov



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [devel] I: lib.req: upgraded "library not found" warnings to errors
  2022-02-06 23:01   ` Dmitry V. Levin
  2022-02-07  3:18     ` Alexey V. Vissarionov
  2022-02-08 20:50     ` Vitaly Lipatov
@ 2022-04-28 11:39     ` Sergey Afonin
  2 siblings, 0 replies; 13+ messages in thread
From: Sergey Afonin @ 2022-04-28 11:39 UTC (permalink / raw)
  To: ALT Linux Team development discussions

On Monday 07 February 2022, Dmitry V. Levin wrote:

> Тут речь идёт о том, что если некий elf уже слинкован с некоторой
> библиотекой, эта библиотека должна быть доступна для lib.req,
> иначе lib.req оказывается в сложной ситуации.
> 
> А так можно фильтровать и то, что попадает к lib.req, и то,
> что получается на выходе.

Вот теперь кто бы это объяснил компании Oracle...

Что-то я не очень аккуратно воспользовался %add_findreq_skiplist
в mysql-workbench-community 8.0.25-alt5 (в Sisyphus попало уже).
Есть ли путь починить сборку пакета исключениями и оставить 
автоматическое формирование зависимостей на внешние библиотеки?

-- 
С уважением, Сергей Афонин.


^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2022-04-28 11:39 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-02-06 13:41 [devel] I: lib.req: upgraded "library not found" warnings to errors Dmitry V. Levin
2022-02-06 22:44 ` Alexey V. Vissarionov
2022-02-06 23:01   ` Dmitry V. Levin
2022-02-07  3:18     ` Alexey V. Vissarionov
2022-02-08 20:50     ` Vitaly Lipatov
2022-02-09  0:11       ` Dmitry V. Levin
2022-02-09  0:54         ` Vitaly Lipatov
2022-04-28 11:39     ` Sergey Afonin
2022-02-09  3:11 ` Evgeniy Kukhtinov
2022-02-09 11:15   ` Dmitry V. Levin
2022-02-09 12:12     ` Vitaly Lipatov
2022-02-09 12:46       ` Dmitry V. Levin
2022-02-27 13:15         ` Yuri Sedunov

ALT Linux Team development discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \
		devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru
	public-inbox-index devel

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://lore.altlinux.org/org.altlinux.lists.devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git