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 6/8/22 16:14, Peter McD wrote:
Hi,
Updated from Leap 15.3 to Leap 15.4 today. No problems so far, except(!)
Darktable doesn't work anymore. <snip> console printed:
peter@lux-2:~> darktable darktable: error while loading shared libraries: libdarktable.so: cannot open shared object file: No such file or directory
Did it by chance identify which .so wasn't found? -- David C. Rankin, J.D.,P.E.
On 09.06.2022 00:14, Peter McD wrote:
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.
Where does it come from? Leap 15.3 has draktable 3.4.
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.
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:
On 09.06.2022 00:14, Peter McD wrote:
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.
Where does it come from? Leap 15.3 has draktable 3.4.
Additional Repo: https://download.opensuse.org/repositories/home:Simmphonie/openSUSE_Leap_15....
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.
you have non-standard configuration so you need to make sure nothing left from another version you used before.
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
On 09.06.2022 12:15, Peter McD wrote:
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.
Yes, I can confirm it. You should open bug report for Leap 15.4. As a workaround you could use LD_LIBRARY_PATH=/usr/lib64/darktable darktable or ln -s darktable/libdarktable.so /usr/lib64
Am 09.06.22 um 13:08 schrieb Andrei Borzenkov:
On 09.06.2022 12:15, Peter McD wrote:
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.
Yes, I can confirm it. You should open bug report for Leap 15.4. As a workaround you could use
LD_LIBRARY_PATH=/usr/lib64/darktable darktable
or
ln -s darktable/libdarktable.so /usr/lib64
Thanks! Peter
Am 09.06.22 um 13:08 schrieb Andrei Borzenkov:
On 09.06.2022 12:15, Peter McD wrote:
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.
Yes, I can confirm it. You should open bug report for Leap 15.4. As a workaround you could use
LD_LIBRARY_PATH=/usr/lib64/darktable darktable
or
ln -s darktable/libdarktable.so /usr/lib64
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
Am 09.06.22 um 13:08 schrieb Andrei Borzenkov:
On 09.06.2022 12:15, Peter McD wrote:
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.
Yes, I can confirm it. You should open bug report for Leap 15.4. As a workaround you could use
LD_LIBRARY_PATH=/usr/lib64/darktable darktable
or
ln -s darktable/libdarktable.so /usr/lib64
Symlink set: ln -s /usr/lib64/darktable/libdarktable.so /usr/lib64/libdarktable.so Works. Peter
Hello, On Fri, 10 Jun 2022, Peter McD wrote:
Am 09.06.22 um 13:08 schrieb Andrei Borzenkov:
On 09.06.2022 12:15, Peter McD wrote:
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.
Yes, I can confirm it. You should open bug report for Leap 15.4. As a workaround you could use
LD_LIBRARY_PATH=/usr/lib64/darktable darktable
or
ln -s darktable/libdarktable.so /usr/lib64
Symlink set: ln -s /usr/lib64/darktable/libdarktable.so /usr/lib64/libdarktable.so
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
Am 10.06.22 um 18:57 schrieb David Haller:
Hello,
On Fri, 10 Jun 2022, Peter McD wrote:
Am 09.06.22 um 13:08 schrieb Andrei Borzenkov:
On 09.06.2022 12:15, Peter McD wrote:
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.
Yes, I can confirm it. You should open bug report for Leap 15.4. As a workaround you could use
LD_LIBRARY_PATH=/usr/lib64/darktable darktable
or
ln -s darktable/libdarktable.so /usr/lib64
Symlink set: ln -s /usr/lib64/darktable/libdarktable.so /usr/lib64/libdarktable.so
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
Thanks! I expect the bug will be removed really soon:-) Peter
On Fri, 10 Jun 2022 18:57:49 +0200 David Haller <dnh@opensuse.org> wrote:
Hello,
On Fri, 10 Jun 2022, Peter McD wrote:
Am 09.06.22 um 13:08 schrieb Andrei Borzenkov:
On 09.06.2022 12:15, Peter McD wrote:
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.
Yes, I can confirm it. You should open bug report for Leap 15.4. As a workaround you could use
LD_LIBRARY_PATH=/usr/lib64/darktable darktable
or
ln -s darktable/libdarktable.so /usr/lib64
Symlink set: ln -s /usr/lib64/darktable/libdarktable.so /usr/lib64/libdarktable.so
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
Maybe that is removed because /../ links can be easily reinterpreted by bad actors? So it's a security risk. Just guessing :) But whoever removed it should have fixed the consequences!!!
HTH, -dnh
Hello, On Fri, 10 Jun 2022, Dave Howorth wrote:
David Haller <dnh@opensuse.org> 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
Maybe that is removed because /../ links can be easily reinterpreted by bad actors? So it's a security risk. Just guessing :)
$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:
Hello,
On Fri, 10 Jun 2022, Dave Howorth wrote:
David Haller <dnh@opensuse.org> 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
Maybe that is removed because /../ links can be easily reinterpreted by bad actors? So it's a security risk. Just guessing :)
$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
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:
On 6/10/22 18:52, David Haller 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.
Is my patchelf broken or is --add-rpath intended as --set-rpath? Which
Depends on the version. E.g. v0.10 does not have --add-rpath, v0.14 has it.
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.
Yep.
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?
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
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;)
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:
On 09.06.2022 12:15, Peter McD wrote:
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.
Yes, I can confirm it. You should open bug report for Leap 15.4. As a workaround you could use
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
Am 14.06.22 um 12:53 schrieb Simon Lees:
On 6/9/22 20:38, Andrei Borzenkov wrote:
On 09.06.2022 12:15, Peter McD wrote:
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.
Yes, I can confirm it. You should open bug report for Leap 15.4. As a workaround you could use
Bug has been reported by others as https://bugzilla.opensuse.org/show_bug.cgi?id=1200483
True, as I already reported on 2022-06-09. "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." Peter
On 14.06.2022 13:53, Simon Lees wrote:
On 6/9/22 20:38, Andrei Borzenkov wrote:
On 09.06.2022 12:15, Peter McD wrote:
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.
Yes, I can confirm it. You should open bug report for Leap 15.4. As a workaround you could use
Bug has been reported by others as https://bugzilla.opensuse.org/show_bug.cgi?id=1200483
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.
On 6/15/22 00:43, Andrei Borzenkov wrote:
Bug has been reported by others as https://bugzilla.opensuse.org/show_bug.cgi?id=1200483
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 coursehttp://bugzilla.opensuse.org/show_bug.cgi?id=1200482 is not accessible.
I'm completely denied even seeing the bug? That's weird as hell. -- David C. Rankin, J.D.,P.E.
participants (7)
-
Andrei Borzenkov -
Dave Howorth -
David C. Rankin -
David C. Rankin -
David Haller -
Peter McD -
Simon Lees