Skip to main content ↑ ↓
Topic solved
This topic has been marked as solved and requires no further attention.
Topic: libtiff: Library dependency problems in at least xsane and digikam. (Read 1547 times) previous topic - next topic
0 Members and 10 Guests are viewing this topic.

Re: libtiff: Library dependency problems in at least xsane and digikam.

Reply #15 –
Sorry, my last message had a bad error that might have confused you. What had to be moved from testing was the prison package. Digikam actually indirectly depends on that. That's where the linking error was coming from. It make take a few hours for the mirrors to sync.

Re: libtiff: Library dependency problems in at least xsane and digikam.

Reply #16 –
Quote from: Dudemanguy – on
Sorry, my last message had a bad error that might have confused you. What had to be moved from testing was the prison package. Digikam actually indirectly depends on that. That's where the linking error was coming from. It make take a few hours for the mirrors to sync.

I have installed prison version 5.101.0-2.1, build date Fr 13 Jan 2023 20:21:22 CET. So that should be the new one, but I get library error.

Re: libtiff: Library dependency problems in at least xsane and digikam.

Reply #17 –
In that case, I'm not sure what it is. I'm running prison 5.101.0-2.1 and digikam 7.9.0-4. Unless there's some other secret dependency I'm missing that I happen to have installed and you don't?

Edit: okay hopefully prison-5.101.0-2.3 does the trick.

Re: libtiff: Library dependency problems in at least xsane and digikam.

Reply #18 –
Quote from: Dudemanguy – on
In that case, I'm not sure what it is. I'm running prison 5.101.0-2.1 and digikam 7.9.0-4. Unless there's some other secret dependency I'm missing that I happen to have installed and you don't?

Edit: okay hopefully prison-5.101.0-2.3 does the trick.

I just did a full pacman -Syu and the zxing-cpp dependency problem  is fixed, but the libtiff problem is still there.

I see that digikam now is at version 7.9.0-4.1.

I also did re-install all first-level dependencies of digikam, as well all packages that depend on libtiff.

When I look at digikam via 
ldd /usr/bin/digikam | grep tiff, 
I see that it wants libtiff.so.6 and libtiff.so.5:
Code: [Select]
	libtiff.so.6 => /usr/lib/libtiff.so.6 (0x00007f858702f000)
	libtiff.so.5 => not found

What is going on here?

After I installed libtiff5 from the AUR, digikam starts.


Quote from: gripped – on
I've had another think about this. It's a strange logic imho. Adding the Arch repos is 'unsupported'. Yet if there was truly a decision to update libtiff to prevent breakage of packages installed from the Arch repos, knowingly (or not) breaking libtiff dependant packages in the Artix repo, it comes across as - in this instance - Arch repo users were more supported than pure Artix users.

When adding Arch repositories like "community" or "extra" is explicitly unsupported, then I see it as a "bug in Artix governance" when packages are pushed to new versions to make Arch packages not break but thereby risking breaking of Artix packages. 
In this case I come back that upgrades should be "atomic" in the sense that newly built packages should only be moved to the production repositories when all the packages that are connected via dependencies also got a clean rebuild, and then the move should be done at the same time for all packages within one dependency graph. 
What can be done that package breaking due to partial update in the repositories is much less likely to happen in the future?

Regards!

Re: libtiff: Library dependency problems in at least xsane and digikam.

Reply #19 –
Quote from: dreieck – on
When I look at digikam via 
ldd /usr/bin/digikam | grep tiff, 
I see that it wants libtiff.so.6 and libtiff.so.5:
Code: [Select]
	libtiff.so.6 => /usr/lib/libtiff.so.6 (0x00007f858702f000)
	libtiff.so.5 => not found

What is going on here?

Regards!

Something is definitely weird here. Mine only links to version 6.

Code: [Select]
$ ldd /usr/bin/digikam | grep tiff
	libtiff.so.6 => /usr/lib/libtiff.so.6 (0x00007f2c7cd9b000)

Does anybody else have @dreieck's issue?

Re: libtiff: Library dependency problems in at least xsane and digikam.

Reply #20 –
Me. On a new installation made yesterday.

Code: [Select]
$ ldd /usr/bin/digikam | grep tiff
        libtiff.so.6 => /usr/lib/libtiff.so.6 (0x00007f51fd627000)
        libtiff.so.5 => not found

Re: libtiff: Library dependency problems in at least xsane and digikam.

Reply #21 –
Can confirm:
Directly installed from https://mirrors.dotsrc.org/artix-linux/repos/world/os/x86_64/digikam-7.9.0-4.1-x86_64.pkg.tar.zst
Code: [Select]
❯ ldd /usr/bin/digikam | grep tiff
        libtiff.so.5 => not found
        libtiff.so.6 => /usr/lib/libtiff.so.6 (0x00007f05059a2000)

Locally built from https://gitea.artixlinux.org/packagesD/digikam.git the same, and this is in the cmake output
Code: [Select]
[ 95%] Building CXX object core/dplugins/bqm/convert/converttodng/CMakeFiles/Bqm_ConvertToDNG_Plugin.dir/converttodng.cpp.o
/usr/bin/ld: warning: libtiff.so.5, needed by /usr/lib/libopencv_imgcodecs.so.406, not found (try using -rpath or -rpath-link)
[ 95%] Building CXX object core/dplugins/bqm/decorate/border/CMakeFiles/Bqm_Border_Plugin.dir/borderplugin.cpp.o
I had a thought to rebuild whatever provides libopencv_imgcodecs.so
Code: [Select]
❯ pkgfile /usr/lib/libopencv_imgcodecs.so
world/opencv
world/opencv-cuda
extra/opencv
extra/opencv-cuda

opencv  is what I have installed but building that failed
Code: [Select]
/usr/bin/ld: CMakeFiles/opencv_rgbd.dir/src/dynafu.cpp.o: in function `cv::dynafu::DynaFuImpl<cv::Mat>::DynaFuImpl(cv::kinfu::Params const&)':
dynafu.cpp:(.text._ZN2cv6dynafu10DynaFuImplINS_3MatEEC2ERKNS_5kinfu6ParamsE[_ZN2cv6dynafu10DynaFuImplINS_3MatEEC5ERKNS_5kinfu6ParamsE]+0x3c8): undefined reference to `glGenRenderbuffersEXT'
/usr/bin/ld: dynafu.cpp:(.text._ZN2cv6dynafu10DynaFuImplINS_3MatEEC2ERKNS_5kinfu6ParamsE[_ZN2cv6dynafu10DynaFuImplINS_3MatEEC5ERKNS_5kinfu6ParamsE]+0x3d6): undefined reference to `glBindRenderbufferEXT'
/usr/bin/ld: dynafu.cpp:(.text._ZN2cv6dynafu10DynaFuImplINS_3MatEEC2ERKNS_5kinfu6ParamsE[_ZN2cv6dynafu10DynaFuImplINS_3MatEEC5ERKNS_5kinfu6ParamsE]+0x3ec): undefined reference to `glRenderbufferStorageEXT'
/usr/bin/ld: dynafu.cpp:(.text._ZN2cv6dynafu10DynaFuImplINS_3MatEEC2ERKNS_5kinfu6ParamsE[_ZN2cv6dynafu10DynaFuImplINS_3MatEEC5ERKNS_5kinfu6ParamsE]+0x3fb): undefined reference to `glGenFramebuffersEXT'
/usr/bin/ld: dynafu.cpp:(.text._ZN2cv6dynafu10DynaFuImplINS_3MatEEC2ERKNS_5kinfu6ParamsE[_ZN2cv6dynafu10DynaFuImplINS_3MatEEC5ERKNS_5kinfu6ParamsE]+0x409): undefined reference to `glBindFramebufferEXT'
/usr/bin/ld: dynafu.cpp:(.text._ZN2cv6dynafu10DynaFuImplINS_3MatEEC2ERKNS_5kinfu6ParamsE[_ZN2cv6dynafu10DynaFuImplINS_3MatEEC5ERKNS_5kinfu6ParamsE]+0x421): undefined reference to `glFramebufferRenderbufferEXT'
/usr/bin/ld: dynafu.cpp:(.text._ZN2cv6dynafu10DynaFuImplINS_3MatEEC2ERKNS_5kinfu6ParamsE[_ZN2cv6dynafu10DynaFuImplINS_3MatEEC5ERKNS_5kinfu6ParamsE]+0x430): undefined reference to `glGenRenderbuffersEXT'
/usr/bin/ld: dynafu.cpp:(.text._ZN2cv6dynafu10DynaFuImplINS_3MatEEC2ERKNS_5kinfu6ParamsE[_ZN2cv6dynafu10DynaFuImplINS_3MatEEC5ERKNS_5kinfu6ParamsE]+0x43e): undefined reference to `glBindRenderbufferEXT'
/usr/bin/ld: dynafu.cpp:(.text._ZN2cv6dynafu10DynaFuImplINS_3MatEEC2ERKNS_5kinfu6ParamsE[_ZN2cv6dynafu10DynaFuImplINS_3MatEEC5ERKNS_5kinfu6ParamsE]+0x454): undefined reference to `glRenderbufferStorageEXT'
/usr/bin/ld: dynafu.cpp:(.text._ZN2cv6dynafu10DynaFuImplINS_3MatEEC2ERKNS_5kinfu6ParamsE[_ZN2cv6dynafu10DynaFuImplINS_3MatEEC5ERKNS_5kinfu6ParamsE]+0x46c): undefined reference to `glFramebufferRenderbufferEXT'
collect2: error: ld returned 1 exit status
make[2]: *** [modules/rgbd/CMakeFiles/opencv_rgbd.dir/build.make:504: lib/libopencv_rgbd.so.4.7.0] Error 1
make[1]: *** [CMakeFiles/Makefile2:9507: modules/rgbd/CMakeFiles/opencv_rgbd.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
I'm going to try it in a chroot......

opencv version in Arch and Artix.

Reply #22 –
Quote from: gripped – on
Locally built from https://gitea.artixlinux.org/packagesD/digikam.git the same, and this is in the cmake output
Code: [Select]
[ 95%] Building CXX object core/dplugins/bqm/convert/converttodng/CMakeFiles/Bqm_ConvertToDNG_Plugin.dir/converttodng.cpp.o
/usr/bin/ld: warning: libtiff.so.5, needed by /usr/lib/libopencv_imgcodecs.so.406, not found (try using -rpath or -rpath-link)
[ 95%] Building CXX object core/dplugins/bqm/decorate/border/CMakeFiles/Bqm_Border_Plugin.dir/borderplugin.cpp.o

OK, opencv.

Just for information, if it might be helpful: Arch's extra/opencv is at version 4.7.0-1, Artix' world/opencv at version 4.6.0-6.

Regards!

Re: libtiff: Library dependency problems in at least xsane and digikam.

Reply #23 –
The newest version (4.7.0-2) at https://gitea.artixlinux.org/packagesO/opencv built successfully in a chroot
Installed the resulting package and built and installed digikam. It was now correctly linked
Code: [Select]
❯ ldd /usr/bin/digikam | grep tiff
        libtiff.so.6 => /usr/lib/libtiff.so.6 (0x00007fa00a9ae000)

Re: libtiff: Library dependency problems in at least xsane and digikam.

Reply #24 –
Sorry for all the issues. There was an opencv in staging, testing, and world at the same time I totally didn't see the testing one (and was using it on my machine because I usually run testing repos). I have moved that to world now hopefully for real this time.

digikam and gst-plugin-opencv linked against wrong opencv version.

Reply #25 –
Now the updated opencv is available in the Artix repos, thanks for that!

But digikam is still build against the old opencv, so again failing, now because of wrong opencv dependency:

ldd /usr/bin/digikam | grep -E '(opencv|tiff)': 
Code: [Select]
	libopencv_dnn.so.406 => not found
	libopencv_imgproc.so.406 => not found
	libopencv_ml.so.406 => not found
	libopencv_core.so.406 => not found
	libtiff.so.6 => /usr/lib/libtiff.so.6 (0x00007fc51000e000)
	libopencv_imgcodecs.so.406 => not found
	libopencv_dnn.so.406 => not found
	libopencv_imgproc.so.406 => not found
	libopencv_core.so.406 => not found

I have done a full upgrade.

world/opencv is version 4.7.0-1, world/digikam is version 7.9.0-4.1.

Since the system update did not update much, I suspect also other packages are affected. I could identify at least world/gst-plugin-opencv (version 1.20.5-5).

Can you please push new versions to official (non-testing/ non-staging) repositories only when all packages of a dependency graph have been rebuilt, and then push all packages belonging to the new dependency graph at once?

Or can anyone enlighten me why this is not feasible? Bzw. what can be helped that things can work that or another way with a comparable result?

Regards!
 

Re: libtiff: Library dependency problems in at least xsane and digikam.

Reply #26 –
Quote from: dreieck – on
Can you please push new versions to official (non-testing/ non-staging) repositories only when all packages of a dependency graph have been rebuilt, and then push all packages belonging to the new dependency graph at once?

That's what normally happens but this one has been an absolute linking clusterfucker of multiple library version updates, things I didn't even know it depended on, and packages in repos I didn't even know were there. Rebuilt again and hopefully solved?

Re: libtiff: Library dependency problems in at least xsane and digikam.

Reply #27 –
Quote from: Dudemanguy – on
That's what normally happens but this one has been an absolute linking clusterfucker of multiple library version updates, things I didn't even know it depended on, and packages in repos I didn't even know were there.

Are there no tools to automatically check for it and by default deny any update, only when the check passes allow update?

Quote from: Dudemanguy – on
Rebuilt again and hopefully solved?

Yes, thanks!