Closed bartoszek closed 4 years ago
Perhaps good practice would be to limit ldd -r
call to only libraries that the linker has access to
ldconfig -vN
I'm not well versed at this yet, can you please explain what this will achieve - we will go through executable files, and if they are present in ldconfig -vN
(i.e. more or less if they are in /usr/lib/
we will check them with ldd -r
, but otherwise we will check them with plain ldd
?
It they,re not in ldconfig -vN
will ignore them, as ld
can't guarantee that shared objects outside of it's scope can be resolved without extra info.
But at the same time this only must apply to libraries, somehow? Thinking of your original example on AUR, we do want to run ldd -r
on /usr/bin/yay
even though this is not in ldconfig -vN
...
Yep, we'll have to separate binaries and libraries, I'll think of a sample implementation, perhaps reverse ldd
search will do...
Just as an idea, what do you think if we cross-reference files with $PATH
, and if the file is in $PATH
then we execute ldd -r
and otherwise plain ldd
?
Problem with
-r
flag inldd
call relates to reverse dependency not having info from caller to help resolve its consecutive dependencies. Take for example meshlab There is no need for plugins to haverpath
defined as they are linked frommeshlab
and inherite itsrpath
Basically calling ldd -r on libs is quite fragile...