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
