Bug#1039714: gobject-introspection: dh_girepository does not fetch all symbols from GIR files
On Fri, 30 Jun 2023, أحمد المحمودي wrote: On Wed, Jun 28, 2023 at 05:00:10PM +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. ---end quoted text--- But why doesn't this bug show itself on sparc64 arch ? Both gir1.2-harfbuzz and gir1.2-freedesktop depend on their respective library packages on sparc64 archs only. This is because --as-needed is passed as linker flag since debhelper 13 which is not working on sparc architectures. So the temporarily generated dummy library would link to libharfbuzz-gobject.so.0 on sparc64 although it would not use any of its symbols. You can see this from the minimal version that is annotated to libharfbuzz-gobject0 for instance which is 0.9.20 (with unpatched dh_girepository). That is the lowest version number in libharfbuzz-gobject0.symbols. But correct would have been 5.1.0 which is the minimal version you get with the patched dh_girepository because of hb_gobject_draw_funcs_get_type() which was introduzed in harfbuzz 4.0.0. So version 5.1.0-1 was the very first version in Debian with that symbol. Best regards, Thomas Uhle
Bug#1039714: gobject-introspection: dh_girepository does not fetch all symbols from GIR files
On Wed, Jun 28, 2023 at 05:00:10PM +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. ---end quoted text--- But why doesn't this bug show itself on sparc64 arch ? Both gir1.2-harfbuzz and gir1.2-freedesktop depend on their respective library packages on sparc64 archs only. -- أحمد المحمودي (Ahmed El-Mahmoudy) Digital design engineer GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7 GPG Fingerprints: 6E2E E4BB 72E2 F417 D066 6ABF 7B30 B496 A7EF 5761 8206 A196 2084 7E6D 0DF8 B176 BC19 6A94 EDDD A1B7 signature.asc Description: PGP signature
Bug#1039714: gobject-introspection: dh_girepository does not fetch all symbols from GIR files
Hello Simon,
thanks a lot for this nice description!
I am also not an author of dh_girepository but happen to understand Perl
code. So I had to work out how it works just from the code. I am sorry
that I was a bit short in my previous e-mail. I could have delivered some
more explaining thoughts. As far as I understand, it was easier for the
author(s) of dh_girepository to utilize dpkg-shlibdeps to determine the
dependencies on shared libraries. That is why dh_girepository simply
dumps every found symbol in a dummy C file that is then compiled and
linked to a shared library itself (for each GIR file a seperate shared
library). dpkg-shlibdeps uses these temporarily built shared libraries
to determine the dependencies. So dh_girepository does not need to look
up each and every symbol in /var/lib/dpkg/info/*.symbols itself to
generate ${gir:Depends} into debian/gir1.2-*.substvars.
You are right, the code responsible for parsing the GIR file was just
recognizing symbols that resemble ordinary functions, methods and
constructors and ignoring other symbols. In the case of HarfBuzz-0.0.gir
this has led to the situation that the *_get_type() function from
libharfbuzz-gobject.so.0 were ignored and, thus, not in the dummy C file.
Because these functions has yet been the only functions in
libharfbuzz-gobject.so.0, dpkg-shlibdeps could not determine the
dependency to this shared library and so libharfbuzz-gobject0 has been
missing in ${gir:Depends} and finally in the control file of
gir1.2-harfbuzz-0.0.
That is why I have studied gir-1.2.rnc (part of libgirepository1.0-dev)
to find out which XML elements are used for native symbols. Apart from
(virtual) methods, constructors and ordinary functions, these symbols can
also be part of the definitions of types such as classes, interfaces,
enumeration types, records, unions, etc. While adding support for virtual
methods was quite easy by simply tweaking the already existing regular
expression, I had to make up a new regular expression for parsing the XML
attributes of the type definitions. Next to *_get_type(), there can also
be functions for the reference counting of objects, getters and setters.
That is why this new regular expression is a little more complex than the
one that was already there.
On Wed, 28 Jun 2023, Simon McVittie wrote:
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?
That is perfect. Thanks a lot!
Best regards,
Thomas
Bug#1039714: gobject-introspection: dh_girepository does not fetch all symbols from GIR files
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
Bug#1039714: gobject-introspection: dh_girepository does not fetch all symbols from GIR files
Control: affects -1 gir1.2-freedesktop Dear maintainers, this issue is also the reason why gir1.2-freedesktop is missing the dependency on libcairo-gobject0 although libcairo-gobject.so.2 is referenced by cairo-1.0.typelib as well as cairo-1.0.gir. With the patch from my last e-mail that would be fixed as well. Best regards, Thomas Uhle
