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

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

Symlink set: ln -s /usr/lib64/darktable/libdarktable.so /usr/lib64/libdarktable.so Works. Peter

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

Hello, On Fri, 10 Jun 2022, Dave Howorth wrote:

David Haller 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

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 13:04, David C. Rankin wrote:

Went with

# patchelf --add-rpath '$ORIGIN/../lib64/darktable' /usr/bin/darktable

Correction: # patchelf --set-rpath '$ORIGIN/../lib64/darktable' /usr/bin/darktable -- David C. Rankin, J.D.,P.E.

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 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.