Hi, Updated from Leap 15.3 to Leap 15.4 today. No problems so far, except(!) Darktable doesn't work anymore. I have been using Darktable 3.8 with Leap 15.3. After the upgrade there was Darktable 3.6, which is standard in leap 15.4. Neither Darktable icon nor console as user could start the program. console printed: peter@lux-2:~> darktable darktable: error while loading shared libraries: libdarktable.so: cannot open shared object file: No such file or directory Something is missing. Peter
On 09.06.2022 00:14, Peter McD wrote:
Where does it come from? Leap 15.3 has draktable 3.4.
you have non-standard configuration so you need to make sure nothing left from another version you used before. Does libdatktable.so exist (should be in /usr/lib64/darktable)? Are you sure you are actually running darktable binary from openSUSE and not some other binary from your darktable 3.8?
Am 09.06.22 um 05:57 schrieb Andrei Borzenkov:
Additional Repo: https://download.opensuse.org/repositories/home:Simmphonie/openSUSE_Leap_15....
Last night I renamed all darktable related directories/files in HOME to darktable_3.8 and removed darktable 3.8 via YAST, then installed standard darktable 3.6 from Leap 15.4 Again no start: peter@lux-2:~> darktable darktable: error while loading shared libraries: libdarktable.so: cannot open shared object file: No such file or directory
Does libdatktable.so exist (should be in /usr/lib64/darktable)?
lux-2:~ # find /usr/lib64 -iname '*darktable*' /usr/lib64/qt5/plugins/digikam/rawimport/RawImport_DarkTable_Plugin.so /usr/lib64/darktable /usr/lib64/darktable/plugins/lighttable/libdarktable_label.so /usr/lib64/darktable/libdarktable.so /usr/lib64/gimp/2.0/plug-ins/file-darktable /usr/lib64/gimp/2.0/plug-ins/file-darktable/file-darktable It exists but darktable doesn't find it. Another test, darktable for the first time in my virtual Leap 15.4 RC via Yast. It doesn't start, same error message: peter@lupo:~> darktable darktable: error while loading shared libraries: libdarktable.so: cannot open shared object file: No such file or directory So the problem is not related to a previously installed darktable version. Peter
Am 09.06.22 um 13:08 schrieb Andrei Borzenkov:
A bug report already exists:-( Bug Bug 1160071 first reported 2020-01-03 15:03 UTC by Paul Tannington Darktable fails to open. Claims libdarktable.so "No such file" I added a comment. I suppose everybody has been using the workaround. Peter
Hello, On Fri, 10 Jun 2022, Peter McD wrote:
An (better) alternative is undoing the removal of the rpath that darktable is normally compiled with: # patchelf --add-rpath '$ORIGIN/../lib64/darktable' /usr/bin/darktable HTH, -dnh -- Door: Something a cat wants to be on the other side of
Hello, On Fri, 10 Jun 2022, Dave Howorth wrote:
$ORIGIN is a linker-internal variable expanding to the directory of the file, i.e. /usr/bin/ here. And anyway, that's just what's linked in per default during compilation unless removed. There's no reason for not to hard-code /usr/lib64/darktable. And AFAIR it can be arranged that way during compilation/linking. E.g. patchelf --set-rpath %{_libdir}/darktable \ %{buildroot}%{_bindir}/darktable or something in the RPM-specfile for darktable after in the %install section. HTH, -dnh -- printk(KERN_CRIT "How did I get here?\n"); linux-2.6.19/arch/mips/kernel/syscall.c
On 6/10/22 18:52, David Haller wrote:
dnh, Is my patchelf broken or is --add-rpath intended as --set-rpath? Which brings up another question. "add rpath" sounds attractive because if the current rpath simply excludes /usr/lib64/darktable/libdarktable.so, then "adding" to it is what I would want to do. However if --set-rpath completely replaces the information -- then that sounds like I may overwrite the info with the single library location. Now it would make sense that the only rpath info would be for /usr/lib64/darktable/libdarktable.so, but how would I check the executable to see if there is other rpath information contained? readelf in some form? -- David C. Rankin, J.D.,P.E.
Hello, On Sun, 12 Jun 2022, David C. Rankin wrote:
Depends on the version. E.g. v0.10 does not have --add-rpath, v0.14 has it.
Yep.
There's various ways, but 'patchelf --print-rpath' seems logical. And I doubt very much that darktable has any rpath set, so you can just go ahead and use --set-rpath which does replace the rpath as you suspect. In the general case, you could use: OLD_RPATH=$(patchelf --print-rpath foo) patchelf --set-rpath "/opt/foo/lib${OLD_RPATH:+:${OLD_RPATH}}" The weird ':+' only adds a : and the contents of OLD_RPATH if that is set and nothing if it's not set or empty. Alternatively, you could contstruct the new rpath thus: OLD_RPATH=$(patchelf --print-rpath foo) RPATH="/opt/foo/lib" [[ -n $OLD_RPATH ]] && RPATH+=":${RPATH}" patchelf --set-rpath "$RPATH" So, there's ways around the "missing" --add-rpath ;) HTH, -dnh -- Kiss me twice. I'm schizophrenic. -- from the BSD fortune file
On 6/13/22 09:13, David Haller wrote:
There's various ways, but 'patchelf --print-rpath' seems logical.
Can't believe I skipped over that and went to looking in readelf.... Checked -- there is no darktable rpath set
Went with # patchelf --add-rpath '$ORIGIN/../lib64/darktable' /usr/bin/darktable and removed the temporary symlink: /usr/lib64/libdarktable.so -> darktable/libdarktable.so darktable works like a charm (and I don't have to remember to unlink the temporary symlink when the updated version arrives :) Thanks dnh -- David C. Rankin, J.D.,P.E.
On 6/9/22 20:38, Andrei Borzenkov wrote:
Bug has been reported by others as https://bugzilla.opensuse.org/show_bug.cgi?id=1200483 -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On 14.06.2022 13:53, Simon Lees wrote:
Another package broken by the same %cmake -DCMAKE_SKIP_INSTALL_RPATH:BOOL=ON is lxqt (https://forums.opensuse.org/showthread.php/571199-Leap-15-4-clean-install-wi...) Of course http://bugzilla.opensuse.org/show_bug.cgi?id=1200482 is not accessible.
participants (7)
-
Andrei Borzenkov -
Dave Howorth -
David C. Rankin -
David C. Rankin -
David Haller -
Peter McD -
Simon Lees