@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
Thinking about this for a moment, one simple solution comes to mind:
Allow for using a custom base image (or Dockerfile) for `make check`.
This way, our test image would be built on top of whatever custom image you've
chosen. The only requirement would be for that image to itself be based on
Can you point me to such a specimen?
Rpm doesn't know anything about EBPF, the warning/error is based on detecting
ELF files which up to now have been pretty arch-specific.
--
Reply to this email directly or view it on GitHub:
Yep, both rpm-sequoia and popt are something we'd occasionally want to build
from sources instead of packaged versions. So this is actually fairly important
piece, even if we have managed without it so far.
--
Reply to this email directly or view it on GitHub:
That looks like the correct output to me. Why do you think it doesn't work?
Note that %quote does not add any quotes, the effect is purely internal. Here's
how to make it visible:
```
$ rpm --define '%foo(D:) %{shescape %{**}}' --eval '%foo -D"33 44" argument'
'-D"33' '44"' 'argument'
$ rpm
Sometimes what you want to do is also build a dependency of RPM locally, just
like RPM itself, and run the test-suite with that. A prime example being the
rpm-sequoia project which is currently using RPM 4.18 (i.e. the previous
test-suite version using fakechroot) in their CI, see
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
