* [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 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
* 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
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