Bugzilla – Bug 1185700
Digikam 7.2.0 failing to launch.
Last modified: 2022-09-06 16:50:46 UTC
Following an update of Digikam to 7.2.0-214.19 ( from http://download.opensuse.org/repositories/KDE:/Extra/openSUSE_Tumbleweed ) it's failing to launch. Attempting to start from the command line the following is output: paul@Orion-15:~$ digikam No protocol specified QCommandLineParser: already having an option named "h" QCommandLineParser: already having an option named "help-all" QCommandLineParser: already having an option named "v" digikam: symbol lookup error: /usr/lib64/libdigikamgui.so.7.2.0: undefined symbol: _ZN2cv3dnn14dnn4_v202103013NetC1Ev paul@Orion-15:~$
Snapshot 20210504, which included an update to libopencv* has solved this issue. Apologies for the noise.
Re-opened as digikam still fails to launch with the version from "standard" TW OSS repository: paul@Orion-15:~$ zypper se -is *digikam* Loading repository data... Reading installed packages... S | Name | Type | Version | Arch | Repository ---+-----------------+---------+-----------+--------+------------------------ i+ | digikam | package | 7.2.0-1.2 | x86_64 | openSUSE-Tumbleweed-Oss i+ | digikam-plugins | package | 7.2.0-1.2 | x86_64 | openSUSE-Tumbleweed-Oss i+ | libdigikamcore7 | package | 7.2.0-1.2 | x86_64 | openSUSE-Tumbleweed-Oss paul@Orion-15:~$ The version from KDE:Extra starts OK.
It appears to work here, that symbol is provided by libopencv4_5-4.5.2-1.1.x86_64. What's the version of the libopencv4_5 package on your system? Where is it from?
libopencv* is from the standard TW OSS repository With digikam from KDE:Extra all works OK paul@Orion-15:~$ zypper se -is libopencv Loading repository data... Reading installed packages... S | Name | Type | Version | Arch | Repository ---+------------------------+---------+------------+--------+------------------------ i+ | libopencv3_4 | package | 3.4.10-2.4 | x86_64 | openSUSE-Tumbleweed-Oss i | libopencv4_5 | package | 4.5.2-1.1 | x86_64 | openSUSE-Tumbleweed-Oss i | libopencv_imgcodecs4_5 | package | 4.5.2-1.1 | x86_64 | openSUSE-Tumbleweed-Oss i | libopencv_ximgproc4_5 | package | 4.5.2-1.1 | x86_64 | openSUSE-Tumbleweed-Oss paul@Orion-15:~$ zypper se -is *digikam* Loading repository data... Reading installed packages... S | Name | Type | Version | Arch | Repository ---+-----------------+---------+--------------+--------+----------------------- i+ | digikam | package | 7.2.0-214.19 | x86_64 | KDE Extra (Tumbleweed) i+ | digikam-plugins | package | 7.2.0-214.19 | x86_64 | KDE Extra (Tumbleweed) i+ | libdigikamcore7 | package | 7.2.0-214.19 | x86_64 | KDE Extra (Tumbleweed) paul@Orion-15:~$ Changing digikam to that provided by TW OSS standard repository it fails to launch. See also https://forums.opensuse.org/showthread.php/553645-digikam-fails-to-launch-after-current-update where other users are also reporting this issue.
(In reply to Fabian Vogt from comment #3) > It appears to work here, that symbol is provided by > libopencv4_5-4.5.2-1.1.x86_64. What's the version of the libopencv4_5 > package on your system? Where is it from? That was indeed a false positive, it fails with LD_BIND_NOW=1. I asked for a rebuild, that's running now. It appears like OpenCV broke ABI, because the dnn namespace is versioned and that version got bumped: https://github.com/opencv/opencv/commit/a823b06fa5afd0a1c42f032f00a5169bf8ddef1e#diff-635059e6e33138c5734e926dfbb7355b08ce112d9ec542313f0377761bf00da6 Was that change intentional? If so, is it possible to use symbol versioning for that so that it's expressed as RPM dependencies? If not, libdigicamcore7 will need a %requires_eq on libopencv*. The problem in the original comment was using old opencv (old TW) with new digikam (KDE:Extra), while plain TW has new opencv combined with old digikam.
(In reply to Fabian Vogt from comment #5) > (In reply to Fabian Vogt from comment #3) > > It appears to work here, that symbol is provided by > > libopencv4_5-4.5.2-1.1.x86_64. What's the version of the libopencv4_5 > > package on your system? Where is it from? > > That was indeed a false positive, it fails with LD_BIND_NOW=1. > I asked for a rebuild, that's running now. > > It appears like OpenCV broke ABI, because the dnn namespace is versioned and > that version got bumped: > https://github.com/opencv/opencv/commit/ > a823b06fa5afd0a1c42f032f00a5169bf8ddef1e#diff- > 635059e6e33138c5734e926dfbb7355b08ce112d9ec542313f0377761bf00da6 > > Was that change intentional? If so, is it possible to use symbol versioning > for that so that it's expressed as RPM dependencies? Definitely intentional, as DNN API/ABI has changed. cv::dnn is the only module which has broken ABI in a minor version. For all other modules, the soversion/soname is sufficient. I have filed https://github.com/opencv/opencv/issues/20046 > The problem in the original comment was using old opencv (old TW) with new > digikam (KDE:Extra), while plain TW has new opencv combined with old digikam. Why was digikam in TW not rebuild?
(In reply to Stefan Brüns from comment #6) > (In reply to Fabian Vogt from comment #5) > > (In reply to Fabian Vogt from comment #3) > > > It appears to work here, that symbol is provided by > > > libopencv4_5-4.5.2-1.1.x86_64. What's the version of the libopencv4_5 > > > package on your system? Where is it from? > > > > That was indeed a false positive, it fails with LD_BIND_NOW=1. > > I asked for a rebuild, that's running now. > > > > It appears like OpenCV broke ABI, because the dnn namespace is versioned and > > that version got bumped: > > https://github.com/opencv/opencv/commit/ > > a823b06fa5afd0a1c42f032f00a5169bf8ddef1e#diff- > > 635059e6e33138c5734e926dfbb7355b08ce112d9ec542313f0377761bf00da6 > > > > Was that change intentional? If so, is it possible to use symbol versioning > > for that so that it's expressed as RPM dependencies? > > Definitely intentional, as DNN API/ABI has changed. > > cv::dnn is the only module which has broken ABI in a minor version. For all > other modules, the soversion/soname is sufficient. I have filed > https://github.com/opencv/opencv/issues/20046 Thanks, subscribed. > > The problem in the original comment was using old opencv (old TW) with new > > digikam (KDE:Extra), while plain TW has new opencv combined with old digikam. > > Why was digikam in TW not rebuild? Packages in Tumbleweed are only rebuilt when they are no longer installable. That's why symbol versioning or an explicit %requires_eq would solve this particular issue.
With the update from Digikam from version 7.2.0-1.2 to version 7.2.0-1.3 in Tumbleweed snapshot 20210507 Digikam works normally again. I think that the bug report can be closed.
(In reply to Michael Malessa from comment #8) > With the update from Digikam from version 7.2.0-1.2 to version 7.2.0-1.3 in > Tumbleweed snapshot 20210507 Digikam works normally again. I think that the > bug report can be closed. Let's keep it open until a proper fix is applied, otherwise this will happen again on the next OpenCV update. I submitted the %requires_eq in digikam as a (hopefully temporary) workaround: https://build.opensuse.org/request/show/891815 There's nothing more we can do from the digikam side, so reassigning to OpenCV.
This should actually be fixed meanwhile by the new opencv soversion scheme, no? https://github.com/opencv/opencv/pull/21178 > * OpenCV 4.x doesn't guarantee or maintain ABI compatibility: > https://github.com/opencv/opencv/wiki/OE-4.-OpenCV-4 > * We should increase SO version on each release
New opencv version scheme respects ABI