Bug#1060951: libkkc: likely shouldn't add recursive dependencies to Marisa_gir_SCANNERFLAGS

[Simon McVittie]

Control: clone -1 -2
Control: retitle -1 gobject-introspection: multiarch g-ir-scanner doesn't find recursive library dependencies
Control: retitle -2 libkkc: likely shouldn't add recursive dependencies to Marisa_gir_SCANNERFLAGS
Control: reassign -2 libkkc 0.3.5-8
Control: tags -2 + upstream

On Tue, 30 Apr 2024 at 08:23:55 -0400, Boyuan Yang wrote:
> * When manually invoking using /usr/bin/g-ir-scanner, the build is fine.
> 
> * When invoking using /usr/bin/x86_64-linux-gnu-g-ir-scanner, the build
> error (libm not found) will happen, as shown in the build log attached.
> 
> Comparing the invocation of g-ir-scanner with native compilation, the
> only extra flag is the addition of "--use-ldd-
> wrapper=/usr/libexec/gobject-introspection-bin/deb-elf-get-needed". I
> guess this wrapper is doing something bad.

The reason for the regression is that ldd is recursive, but
deb-elf-get-needed is not. In builds that link with -Wl,--as-needed,
explicitly linking the GObject-Introspection "dumper" binary to each
--library is not always enough to produce a direct dependency, which means
we can't find out the SONAME of the library.

I'm testing a patch to make g-ir-scanner explicitly disable
-Wl,--as-needed, so that the SONAMEs can be extracted reliably.

Using ldd to parse the dependencies accidentally works around this (today,
but not necessarily forever) because libm is in its indirect dependencies,
via libstdc++ - but arguably that's wrong, because libm no longer exists
as an independent library and has been merged into libc.

However, I think libkkc is also invoking g-ir-scanner wrong: it's passing
its dependencies into g-ir-scanner as -l (--library). This is not just an
alias of the gcc -l argument: it is specifically intended to be a list
of the libraries that are part of the library for which g-ir-scanner is
generating a binding. By passing "-lstdc++ -lm -lgcc_s -lgio-2.0 ..."
to g-ir-scanner, this project is claiming to be a GObject-Introspection
binding for libstdc++, libm, libgcc_s, libgio-2.0 and so on - which seems
unlikely to be true! So I think it would be worthwhile to fix this in
libkkc as well.

A symptom of this problem is that Marisa.gir contains
shared-library="libstdc++.so.6,libm.so.6,libc.so.6,libgcc_s.so.1"
instead of what I would expect it to contain, which is something more like
shared-library="libmarisa-glib.so" (or perhaps even an empty list or no
attribute at all, because libmarisa seems to be static-only).

Producing GObject-Introspection bindings for static-only libraries is
unusual, so there are probably some rough edges here. The incorrect
shared-library attribute happens to not matter very much, because the
GIR XML is only used to generate Vala bindings and then thrown away,
rather than being installed like GIR XML usually is.

Looking at its git history, I think
https://github.com/ueno/libkkc/commit/16cd162f1c018fcf74435b3ae920d2805eba40e9
was probably not the right thing to do. My Autotools knowledge
is increasingly rusty, so I don't know what the right thing would
have been: perhaps moving $(MARISA_GLIB_STATIC_DEPENDENCIES) into
libmarisa_glib_la_LIBADD and then relying on libtool to pick up the
static-linking dependencies from the .la file in the usual way?
Like this pseudo-patch (untested):

-libmarisa_glib_la_LIBADD = $(GIO_LIBS) $(MARISA_LIBS)
+libmarisa_glib_la_LIBADD = $(GIO_LIBS) $(MARISA_LIBS) $(MARISA_GLIB_STATIC_DEPENDENCIES)
...
-Marisa_gir_SCANNERFLAGS = --pkg-export=marisa-glib --pkg=marisa --namespace=Marisa $(MARISA_GLIB_STATIC_DEPENDENCIES)
+Marisa_gir_SCANNERFLAGS = --pkg-export=marisa-glib --pkg=marisa --namespace=Marisa

Let's use #1060951 for the gobject-introspection regression, and the
bug that I've cloned for the libkkc side of this.

    smcv