Bug#1039714: gobject-introspection: dh_girepository does not fetch all symbols from GIR files
Simon McVittie
smcv at debian.org
Wed Jun 28 20:13:05 BST 2023
On Wed, 28 Jun 2023 at 17:00:10 +0200, Thomas Uhle wrote:
> 2. dh_girepository does not fetch the 41 symbols from HarfBuzz-0.0.gir
> that are compiled into libharfbuzz-gobject.so.0. I have attached a
> small patch for it, so that the missing symbols are also dumped into
> the dummy C file that is temporarily generated and compiled for
> dh_shlibdeps.
> This updated version of dh_girepository would also find another 245
> symbols in Gio-2.0.gir for instance.
Thanks for the patch, please could you add a bit more context for what
it's doing and why it's necessary/correct?
I didn't write dh_girepository, so I'm having to work this out from first
principles, but as far as I understand your patch, the explanation would
go something like this:
---
dh_girepository: Discover more symbols in GIR files
dh_girepository creates and compiles a dummy C library that aims to
refer to all the same symbols that are mentioned in the GIR XML, so that
running dpkg-shlibdeps against that library will generate the union of
all the dependencies that would be necessary to provide all the symbols
that a GObject-Introspection binding could get from the typelib. It does
that by parsing the GIR XML and looking for XML elements that refer to
a C symbol.
It was already able to recognise *some* XML elements that refer to a C
symbol: ordinary methods, constructors, and ordinary functions. But it
didn't recognise virtual methods, the get_type() functions of various
GObject types, or other functions that are conceptually part of a
type such as copy and free functions. The result was that if a library
*only* contains virtual methods and get_type() functions - for example
libharfbuzz-gobject, which exists solely to provide get_type() functions
for objects in libharfbuzz - then no dependency on that library would
be generated, leading to ${gir:Depends} being incomplete.
Closes: #1039714
---
Is that accurate? Or if not that, then what?
(What I'm aiming for here is something that could be a commit message
that will explain to future maintainers what happened here and why,
as described in <https://cbea.ms/git-commit/>.)
Thanks,
smcv
More information about the pkg-gnome-maintainers
mailing list