[Bug ld/24389] can't link soft-float modules with double-float modules

[wilson at gcc dot gnu.org]

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.