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.