On 1/4/20 12:24 AM, Jan Kratochvil wrote:
That librpm dependency is painful anyway as librpm authors do not
like it to be used by 3rd party apps and they prefer popen()ing some
rpm commands instead: > rpmdb locking broken by other-arch rpmquery
https://bugzilla.redhat.com/show_bug.c
On Sat, Jan 4, 2020 at 6:22 PM John Reiser wrote:
>
> On 1/3/20 22:35 UTC, Neal Gompa wrote:
> > On Fri, Jan 3, 2020 at 5:25 PM Jan Kratochvil
> > wrote:
> >>
> >> On Fri, 03 Jan 2020 22:45:52 +0100, Neal Gompa wrote:
> >>> Can someone please explain why gdb dlopen()'s librpm instead of just
> >
On 1/3/20 22:35 UTC, Neal Gompa wrote:
On Fri, Jan 3, 2020 at 5:25 PM Jan Kratochvil wrote:
On Fri, 03 Jan 2020 22:45:52 +0100, Neal Gompa wrote:
Can someone please explain why gdb dlopen()'s librpm instead of just
doing proper compile-time linking?
[[snip]]
gdb.spec could auto-detect t
On Fri, Jan 3, 2020 at 5:25 PM Jan Kratochvil wrote:
>
> On Fri, 03 Jan 2020 22:45:52 +0100, Neal Gompa wrote:
> > Can someone please explain why gdb dlopen()'s librpm instead of just
> > doing proper compile-time linking?
>
> Because when it was written (2008) it was common to transfer /usr/bin/g
On Fri, 03 Jan 2020 22:45:52 +0100, Neal Gompa wrote:
> Can someone please explain why gdb dlopen()'s librpm instead of just
> doing proper compile-time linking?
Because when it was written (2008) it was common to transfer /usr/bin/gdb
binary across OS versions (maybe incl. RHEL) as GDB had only v
Hello,
Can someone please explain why gdb dlopen()'s librpm instead of just
doing proper compile-time linking? Best I can tell, our patches to GDB
support both modes, and it seems to be unnecessarily painful for us to
have to track the soversion like that instead of just letting it pick
it up.
I