On Fri, Jan 3, 2020 at 5:25 PM Jan Kratochvil <jan.kratochvil@xxxxxxxxxx> 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/gdb > binary across OS versions (maybe incl. RHEL) as GDB had only very few shared > library dependencies (no Python that time) which were ABI compatible. > After implementing the rpm functionality the DT_NEEDED of librpm was the only > reason why one could no longer use /usr/bin/gdb across OSes as librpm major > version changes very often. Therefore I changed the DT_NEEDD to dlopen(). > > Nowadays there are tons of DT_NEEDED dependencies of /usr/bin/gdb so one does > not even think about the possibility using the binary on some other OS. > > You are right dlopen() could be changed to DT_NEEDED back. But then rather > this whole librpm dependency patch is being rewritten some other ways (and it > is longer done by me who wrote it in that 2008). 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.cgi?id=486423#c1 > I'm not sure the comments there are still valid today. These days, librpm is used by *a lot* of things, and the the API has been hardened accordingly. There may be newer APIs that do it better, though, and that's worth investigating. > > > 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. > > The positive side is that GDB handles gracefully if the librpm (of proper > version) is missing. But the gdb.spec correctly fails to build it. > > gdb.spec could auto-detect the current librpm version. > I think it'd be nice if it auto-detected this stuff. It's weird having to go and fix that manually. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
