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
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
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
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
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
