Agreed, especially with the [CI gating
part](https://matrix.to/#/!IHsypFkurbRbXzkjTO:matrix.org/$Jo1uzuG9SVrm__zmNvoYXXI2EarBYgIt-WdTu8TPBVg?via=fedora.im=matrix.org=fedoraproject.org).
--
Reply to this email directly or view it on GitHub:
@praiskup It is exactly the same problem. We will continue to have these issues
at the distribution level until we change the way we model how a package
exports an interface e.g. list of shared objects. There is perhaps a broader
question that this mistake would *not* have been caught without
Seems related https://bugzilla.redhat.com/show_bug.cgi?id=2266553
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2872#discussioncomment-8615424
You are receiving this because you are subscribed to this thread.
Message ID:
@pmatilai I agree that while a "search path" is a fundamental part of the model
for the full view of the dynamic loader, it need not be pat of rpm's `elfdeps`
and could become some kind of filter option that is driven by libc specific
search information.
--
Reply to this email directly or
One thing just for the record, up to now elfdeps has been path agnostic by
design to match the dynamic linker: it doesn't matter where those libraries
come from as long as they're in the runtime path. Of course it's not an "end
user tool" but having consistent output regardless of the file
Actually, we'll need to have this path-discovery wrapped in some libc specific
helper script in rpm because this eg musl has an entirely different library
search path mechnism. That's fine though, for glibc we could implement our own
ld.so.conf parser for the immediate use and then once the
Yeah elfdeps basically ignores all path-aspects, it only really handles
DT_NEEDED and DT_SONAME.
One thing here though: a manually added require/provide is not equal to one
discovered by rpm, the latter are tracked on file-level and rpm actually uses
this information. That's why I'm so
@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
Note that I'm specifically avoiding talking about filtering these dependencies
out because I think in many cases its more useful to turn them into something
else instead.
--
Reply to this email directly or view it on GitHub:
Yes, that possible ld.so.conf fragment in the buildroot needs to be covered.
But, I think the hosts ld.so.conf[.d] needs to be processed as well. The
currently building package could be installing to a subdirectory that some
other package (which would have to be a build-dependency) has declared
@pmatilai I realize that my suggestion looks a lot like what you were
attempting to do on a per-package basis? Were you trying to (a) create a
template /etc/ld.so.conf which just includes the the fragment directory, and
for the buildroot of the rpm build (b) allow it to parse any fragments that
When we talk about 1464368 I assume we mean
https://bugzilla.redhat.com/show_bug.cgi?id=1464368
@praiskup When you say "tooling" I expect that between us we need to decide
what we need and why we need it (to document the reason for the feature). Is
there a specific tool you wish you had? What
The above *almost* works. It's just that the ld.so.conf from Fedora causes an
"ldconfig: need absolute file name for configuration file when using -r" error
from ldconfig. Had me scratching hair for a bit because I thought it ws
complaining about the path I was passing in -f which *was*
Yes, a clean way to discover the system library paths searched by the dynamic
loader would go a long way.
Hmm. I guess this is kinda doable by running `ldconfig -r ` followed
by `ldconfig -r -p` from which you can pull the directories (so
effectively the path) or the files themselves. Just do
The last time I observed (few years ago in 1464368) the tooling did not seem to
exist. Would you mind providing such a tool in glibc-devel?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2872#discussioncomment-8241796
You are
@pmatilai Can you expand a bit on what you mean by not liking parsing other
people's config files? Is it that you would like a clean way to discover the
system library paths searched by the dynamic loader?
--
Reply to this email directly or view it on GitHub:
This is one of those topics that gets raised semi-annually at least. To point
out a couple, https://bugzilla.redhat.com/show_bug.cgi?id=2259260 and
https://bugzilla.redhat.com/show_bug.cgi?id=1464368 and
https://github.com/rpm-software-management/rpm/issues/1227 but there are
certainly more
17 matches
Mail list logo
