Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


Relevant part (hopefully):
The full build log is available from:
http://qa-logs.debian.net/2024/01/15/libkkc_0.3.5-8_unstable.log

All bugs filed during this archive rebuild are listed at:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20240115;users=lucas@debian.org
or:
https://udd.debian.org/bugs/?release=na&merged=ign&fnewerval=7&flastmodval=7&fusertag=only&fusertagtag=ftbfs-20240115&fusertaguser=lucas@debian.org&allbugs=1&cseverity=1&ctags=1&caffected=1#results

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

If you reassign this bug to another package, please mark it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

If you fail to reproduce this, please provide a build log and diff it with mine
so that we can identify if something relevant changed in the meantime.

Hi,

This looks like a regression introduced in gobject-introspection
1.78.1-17. For the problematic line below:

* 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.

This bug is affecting multiple packages, including src:libkkc and
src:ibus-anthy (via https://bugs.debian.org/1060953 ). Please consider
looking into them. Please let me know if more debug info is needed.
Thanks!

Regards,
Boyuan Yang
prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -fstack-clash-
protection -Wformat -Werror=format-security -fcf-protection -Wall -
pedantic" LDFLAGS="-Wl,-z,relro -Wl,--as-needed" CC="gcc"
PKG_CONFIG="/usr/bin/pkg-config" GI_HOST_OS="" DLLTOOL="false"
/usr/bin/x86_64-linux-gnu-g-ir-scanner  --add-include-path=. --
namespace=Marisa.gir --nsversion=Marisa --libtool="/bin/bash ../libtool"
--include=GLib-2.0 --include=GObject-2.0 --include=Gio-2.0    --
library=libmarisa-glib.la --pkg-export=marisa-glib --pkg=marisa --
namespace=Marisa -lstdc++ -lm -lgcc_s -lc -lgcc_s --cflags-begin -
I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -
pthread -I/usr/include/libmount -I/usr/include/blkid   -I.. --cflags-end
marisa-key.cc marisa-keyset.cc marisa-agent.cc marisa-trie.cc marisa-
key.h marisa-keyset.h marisa-agent.h marisa-trie.h libmarisa-glib.la --
output Marisa.gir
/<<PKGBUILDDIR>>/marisa-glib/tmp-introspectfgvk9o6l/Marisa-Marisa -
export-dynamic -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -ffile-prefix-
map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -fstack-clash-protection
-Wformat -Werror=format-security -fcf-protection -Wall -pedantic
/<<PKGBUILDDIR>>/marisa-glib/tmp-introspectfgvk9o6l/Marisa-Marisa.o -L.
libmarisa-glib.la -lstdc++ -lm -lgcc_s -lc -lgcc_s -lgio-2.0 -lgobject-
2.0 -Wl,--export-dynamic -lgmodule-2.0 -pthread -lglib-2.0 -lglib-2.0 -
lmarisa -Wl,-z,relro -Wl,--as-needed
introspectfgvk9o6l/Marisa-Marisa -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -
ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -fstack-
clash-protection -Wformat -Werror=format-security -fcf-protection -Wall -
pedantic /<<PKGBUILDDIR>>/marisa-glib/tmp-introspectfgvk9o6l/Marisa-
Marisa.o -Wl,--export-dynamic -Wl,-z -Wl,relro -Wl,--as-needed -Wl,--
export-dynamic  -L. ./.libs/libmarisa-glib.a -lstdc++ -lm -lc -lgcc_s -
lgio-2.0 -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lmarisa -pthread
1.0/Makefile.introspection:156: Marisa.gir] Error 1
http://qa-logs.debian.net/2024/01/15/libkkc_0.3.5-8_unstable.log

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
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):

This successfully mitigates the libkkc issue, and we need it anyway for
ibus-anthy. After uploading that patch, I'll downgrade this bug to non-RC.

I still think this.

Unfortunately this doesn't work, because -lstdc++ gets stripped from the
linker arguments (possibly by libtool), and then the link fails because
the static library needs to use symbols from it.

Possibly adding -Wl,--copy-dt-needed-entries to the Marisa_gir_CFLAGS
would help?

I don't know what the correct solution would be, but I'm reasonably
sure that making Marisa.gir claim to be a GObject binding for libstdc++
is not it.

    smcv

Control: severity -1 normal

gobject-introspection uploaded, downgrading to non-RC.

    smcv