@pmatilai Just for clarity we are leaving out `DT_RPATH`, environmental
combination of `LD_LIBRARY_PATH` and the search paths (packages that alter
shell defaults and global search paths), `LD_PRELOAD` interposition (similar to
`LD_LIBRARY_PATH` but early loads the SONAME), and `DT_RUNPATH` and their
effect on the resolution of the absolute path used to load the DSO *requried*
by either an executable or library. These are AFAIK details that RPM's
`elfdeps` does not model and so still requires the developer to express them
directly as manual requires or provides. This is not a regression in behaviour
just a modelling choice. After all our intent is to make this easier for
developers without needing to expose all of the details around the ELF standard
and the current Linux implementations.
Yes, I agree that the host (or mock chroot) ld.so.conf[.d] paths should be
searched for requires. The still broken case is when the rpm installs a DSO
into a path created by an rpm in the `Requires:` (rather than `BuildRequire:`)
since this cannot be discovered at build time? In this case the rpm neither
provides the ld.so.conf fragment, nor is the DSO used at build time. Is this a
narrow enough case that we can ignore it? Initially my answer is: Yes, I think
we should focus solely on the host ld.so.conf[.d] paths and the paths provided
by the package itself (as it is being built)
It seems natural to use ldconfig to provide these paths? We could add a new
option to just print directories searched.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2872#discussioncomment-8249506
You are receiving this because you are subscribed to this thread.
Message ID:
<rpm-software-management/rpm/repo-discussions/2872/comments/8249...@github.com>
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
