Bug#932287: glib2.0: FTBFS on mips64el: linking 32-bit code with 64-bit code

[Simon McVittie]

Source: glib2.0
Version: 2.59.0-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: debian-mips at lists.debian.org

Something involving GResource appears to have regressed between 2.58.x in
buster/bullseye and the more current GLib in experimental:

> [661/1146] objcopy --add-symbol _g_binary_test1_resource_data=.data:0 gio/tests/test_resources.o gio/tests/test_resources2.o
...
> [924/1146] cc  -o gio/tests/resources gio/tests/test_resources2.o 'gio/tests/bcb7ac7@@resources at exe/meson-generated_.._test_resources.c.o' 'gio/tests/bcb7ac7@@resources at exe/meson-generated_.._test_resources2.c.o' 'gio/tests/bcb7ac7@@resources at exe/meson-generated_.._test_resources_binary.c.o' 'gio/tests/bcb7ac7@@resources at exe/resources.c.o' -Wl,--no-undefined -Wl,--as-needed -g -O2 -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro -Wl,-z,now -Wl,-z,defs -Wl,--no-as-needed -Wl,-O1 -Wl,--start-group glib/libglib-2.0.so.0.5900.0 gmodule/libgmodule-2.0.so.0.5900.0 gobject/libgobject-2.0.so.0.5900.0 gio/libgio-2.0.so.0.5900.0 -Wl,--end-group -pthread '-Wl,-rpath,$ORIGIN/../../glib:$ORIGIN/../../gmodule:$ORIGIN/../../gobject:$ORIGIN/..' -Wl,-rpath-link,/<<PKGBUILDDIR>>/debian/build/deb/glib:/<<PKGBUILDDIR>>/debian/build/deb/gmodule:/<<PKGBUILDDIR>>/debian/build/deb/gobject:/<<PKGBUILDDIR>>/debian/build/deb/gio
> FAILED: gio/tests/resources
> cc  -o gio/tests/resources gio/tests/test_resources2.o 'gio/tests/bcb7ac7@@resources at exe/meson-generated_.._test_resources.c.o' 'gio/tests/bcb7ac7@@resources at exe/meson-generated_.._test_resources2.c.o' 'gio/tests/bcb7ac7@@resources at exe/meson-generated_.._test_resources_binary.c.o' 'gio/tests/bcb7ac7@@resources at exe/resources.c.o' -Wl,--no-undefined -Wl,--as-needed -g -O2 -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro -Wl,-z,now -Wl,-z,defs -Wl,--no-as-needed -Wl,-O1 -Wl,--start-group glib/libglib-2.0.so.0.5900.0 gmodule/libgmodule-2.0.so.0.5900.0 gobject/libgobject-2.0.so.0.5900.0 gio/libgio-2.0.so.0.5900.0 -Wl,--end-group -pthread '-Wl,-rpath,$ORIGIN/../../glib:$ORIGIN/../../gmodule:$ORIGIN/../../gobject:$ORIGIN/..' -Wl,-rpath-link,/<<PKGBUILDDIR>>/debian/build/deb/glib:/<<PKGBUILDDIR>>/debian/build/deb/gmodule:/<<PKGBUILDDIR>>/debian/build/deb/gobject:/<<PKGBUILDDIR>>/debian/build/deb/gio
> /usr/bin/ld: gio/tests/test_resources2.o: warning: linking abicalls files with non-abicalls files
> /usr/bin/ld: gio/tests/test_resources2.o: linking 32-bit code with 64-bit code
> /usr/bin/ld: failed to merge target specific data of file gio/tests/test_resources2.o
> collect2: error: ld returned 1 exit status

Essentially the same thing is still reproducible in 2.60.4-1 and 2.61.1-2.
Presumably some change between 2.58.x and 2.59.0 can be blamed for this.

Maybe GLib's build system is invoking the wrong flavour of objcopy for
mips64el?

It looks like the culprit might be commit d04b9c371d277fa45ba20ad83642e57af50381e7:
https://gitlab.gnome.org/GNOME/glib/commit/d04b9c371d277fa45ba20ad83642e57af50381e7
Is that objcopy invocation wrong for mips64el? Does mips64el objcopy perhaps
default to a different ABI?

    smcv