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