https://sourceware.org/bugzilla/show_bug.cgi?id=24389
--- Comment #1 from Jim Wilson <wilson at gcc dot gnu.org> --- David Abdurachmanov reported the same problem with Fedora over the weekend, but I wasn't able to look at it at the time as SiFive building power was off for maintenance. Building glib to reproduce, I see that the problem starts with the ld command. ld -r -b binary gio/tests/test5.gresource -o gio/tests/test_resources.o which produces output for rv64i/lp64. You called this an unflavored binary, but we don't have that. We have only soft, single, double, and quad-float ABIs encoded in a 2-bit field. Since no ABI was specified, it got the default which is soft-float, which is not link compatible with the double-float ABI used by rv64gc-linux. Maybe we can hack the default to be what we want when built for rv64gc-linux, but in general I don't think this is safe for systems that (potentially) support multiple architectures and ABIs. Or maybe we can add another bit to represent an unspecified ABI and allow an unspecified ABI to link with any other ABI. Looking for more info about this, I found in the glib NEWS file. Overview of changes in GLib 2.59.0 ... * Support `ld -b binary` (on platforms which support it; i.e. Linux) to provide large pre-compiled `GResource` resources with a fast compilation time. (#1489) which takes me to https://gitlab.gnome.org/GNOME/glib/issues/1489 which points at code in gio/tests/meson.build which does # Create object file containing resource data # for testing the external data option if build_machine.system() == 'linux' and for all linux systems it wants to use ld -r -b binary without verifying that this actually works. So this gives diff --git a/gio/tests/meson.build b/gio/tests/meson.build index a3efd33ab..80961c646 100644 --- a/gio/tests/meson.build +++ b/gio/tests/meson.build @@ -559,7 +559,7 @@ if not meson.is_cross_build() or meson.has_exe_wrapper() # Create object file containing resource data # for testing the external data option - if build_machine.system() == 'linux' + if build_machine.system() == 'linux' and build_machine.cpu_family() != 'riscv64' test_gresource_binary = custom_target('test5.gresource', input : 'test5.gresource.xml', output : 'test5.gresource', as a possible workaround, though the reference to build_machine looks funny to me. Shouldn't that be target_machine in case we are cross compiling? It is the target machine ld that matters here. If this is the right solution, then there should be a check for riscv32 also, though that doesn't matter for desktop linux at the moment, just embedded linux. Anyways, I was able to complete a native build with this workaround patch. -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils