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