[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



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@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@exe/meson-generated_.._test_resources.c.o' 'gio/tests/bcb7ac7@@resources@exe/meson-generated_.._test_resources2.c.o' 'gio/tests/bcb7ac7@@resources@exe/meson-generated_.._test_resources_binary.c.o' 'gio/tests/bcb7ac7@@resources@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@exe/meson-generated_.._test_resources.c.o' 'gio/tests/bcb7ac7@@resources@exe/meson-generated_.._test_resources2.c.o' 'gio/tests/bcb7ac7@@resources@exe/meson-generated_.._test_resources_binary.c.o' 'gio/tests/bcb7ac7@@resources@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


Reply to: