Bug 21464 - relocation truncated to fit: R_OR1K_GOT16 on OpenRISC, when linking libQtGui.so.4.8.7
Summary: relocation truncated to fit: R_OR1K_GOT16 on OpenRISC, when linking libQtGui....
Status: RESOLVED FIXED
Alias: None
Product: binutils
Classification: Unclassified
Component: ld (show other bugs)
Version: 2.28
: P2 normal
Target Milestone: ---
Assignee: Stafford Horne
URL:
Keywords:
Depends on: 27746
Blocks:
  Show dependency treegraph
 
Reported: 2017-05-06 13:13 UTC by Thomas Petazzoni
Modified: 2021-05-06 20:24 UTC (History)
3 users (show)

See Also:
Host:
Target: or1k-*-*
Build:
Last reconfirmed: 2021-03-22 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Petazzoni 2017-05-06 13:13:35 UTC
When building the GUI module of Qt 4.8.7 on OpenRISC, the binutils 2.27 linker barfs with:

/home/rclinux/rc-buildroot-test/scripts/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/crtbeginS.o: In function `register_tm_clones':
crtstuff.c:(.text+0xd8): relocation truncated to fit: R_OR1K_GOT16 against undefined symbol `_ITM_registerTMCloneTable'
/home/rclinux/rc-buildroot-test/scripts/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/crtbeginS.o: In function `__do_global_dtors_aux':
crtstuff.c:(.text+0x1e0): relocation truncated to fit: R_OR1K_GOT16 against symbol `__deregister_frame_info@@GLIBC_2.0' defined in .text section in /home/rclinux/rc-buildroot-test/scripts/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/lib/libgcc_s.so
/home/rclinux/rc-buildroot-test/scripts/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/crtbeginS.o: In function `frame_dummy':
crtstuff.c:(.text+0x278): relocation truncated to fit: R_OR1K_GOT16 against symbol `__register_frame_info@@GLIBC_2.0' defined in .text section in /home/rclinux/rc-buildroot-test/scripts/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/lib/libgcc_s.so
crtstuff.c:(.text+0x2c0): relocation truncated to fit: R_OR1K_GOT16 against undefined symbol `_Jv_RegisterClasses'
.obj/debug-shared-emb-generic/qtextdocumentfragment.o: In function `QString::QString()':
/home/rclinux/rc-buildroot-test/scripts/instance-0/output/build/qt-4.8.7/src/gui/../../include/QtCore/../../src/corelib/tools/qstring.h:879:(.text+0x434): relocation truncated to fit: R_OR1K_GOT16 against symbol `QString::shared_null' defined in .data section in /home/rclinux/rc-buildroot-test/scripts/instance-0/output/build/qt-4.8.7/lib/libQtCore.so
/home/rclinux/rc-buildroot-test/scripts/instance-0/output/build/qt-4.8.7/src/gui/../../include/QtCore/../../src/corelib/tools/qstring.h:879:(.text+0x440): relocation truncated to fit: R_OR1K_GOT16 against symbol `QString::shared_null' defined in .data section in /home/rclinux/rc-buildroot-test/scripts/instance-0/output/build/qt-4.8.7/lib/libQtCore.so
/home/rclinux/rc-buildroot-test/scripts/instance-0/output/build/qt-4.8.7/src/gui/../../include/QtCore/../../src/corelib/tools/qstring.h:879:(.text+0x4a8): relocation truncated to fit: R_OR1K_GOT16 against symbol `QString::shared_null' defined in .data section in /home/rclinux/rc-buildroot-test/scripts/instance-0/output/build/qt-4.8.7/lib/libQtCore.so
/home/rclinux/rc-buildroot-test/scripts/instance-0/output/build/qt-4.8.7/src/gui/../../include/QtCore/../../src/corelib/tools/qstring.h:879:(.text+0x4ac): relocation truncated to fit: R_OR1K_GOT16 against symbol `QString::shared_null' defined in .data section in /home/rclinux/rc-buildroot-test/scripts/instance-0/output/build/qt-4.8.7/lib/libQtCore.so
.obj/debug-shared-emb-generic/qtextdocumentfragment.o: In function `QByteArray::QByteArray()':
/home/rclinux/rc-buildroot-test/scripts/instance-0/output/build/qt-4.8.7/src/gui/../../include/QtCore/../../src/corelib/tools/qbytearray.h:400:(.text+0x544): relocation truncated to fit: R_OR1K_GOT16 against symbol `QByteArray::shared_null' defined in .data section in /home/rclinux/rc-buildroot-test/scripts/instance-0/output/build/qt-4.8.7/lib/libQtCore.so
/home/rclinux/rc-buildroot-test/scripts/instance-0/output/build/qt-4.8.7/src/gui/../../include/QtCore/../../src/corelib/tools/qbytearray.h:400:(.text+0x558): relocation truncated to fit: R_OR1K_GOT16 against symbol `QByteArray::shared_null' defined in .data section in /home/rclinux/rc-buildroot-test/scripts/instance-0/output/build/qt-4.8.7/lib/libQtCore.so
.obj/debug-shared-emb-generic/qtextdocumentfragment.o: In function `QString::QString()':
/home/rclinux/rc-buildroot-test/scripts/instance-0/output/build/qt-4.8.7/src/gui/../../include/QtCore/../../src/corelib/tools/qstring.h:879:(.text+0x78c): additional relocation overflows omitted from the output
collect2: error: ld returned 1 exit status

This issue can be reproduced using the following steps:

$ git://git.busybox.net/buildroot
$ cd buildroot/
$ git checkout 25902b111a93e562e3c1991f65c03649c88802c4
$ cat > .config <<EOF
BR2_or1k=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD=y
BR2_TOOLCHAIN_EXTERNAL_URL="http://autobuild.buildroot.net/toolchains/tarballs/br-openrisc-full-2017.02-1096-g54a5333.tar.bz2"
BR2_TOOLCHAIN_EXTERNAL_GCC_5=y
BR2_TOOLCHAIN_EXTERNAL_HEADERS_4_10=y
BR2_TOOLCHAIN_EXTERNAL_LOCALE=y
# BR2_TOOLCHAIN_EXTERNAL_HAS_THREADS_DEBUG is not set
# BR2_TOOLCHAIN_EXTERNAL_HAS_THREADS_NPTL is not set
BR2_TOOLCHAIN_EXTERNAL_CXX=y
BR2_INIT_NONE=y
BR2_SYSTEM_BIN_SH_NONE=y
# BR2_PACKAGE_BUSYBOX is not set
BR2_PACKAGE_QT=y
# BR2_PACKAGE_QT_XML is not set
# BR2_TARGET_ROOTFS_TAR is not set
EOF
$ make olddefconfig
$ make
Comment 1 Andreas Schwab 2017-05-06 13:31:36 UTC
That probably means there are more than 32k GOT entries.  There is no R_OR1K_GOT32 relocation, so it looks like or1k doesn't support such big shared libraries.
Comment 2 Thomas Petazzoni 2017-05-06 13:33:03 UTC
The same issue still exists with binutils 2.28. Steps to reproduce:

$ git://git.busybox.net/buildroot
$ cd buildroot/
$ git checkout 25902b111a93e562e3c1991f65c03649c88802c4
$ cat > .config <<EOF
BR2_or1k=y
BR2_BINUTILS_VERSION_2_28_X=y
BR2_TOOLCHAIN_BUILDROOT_CXX=y
BR2_INIT_NONE=y
BR2_SYSTEM_BIN_SH_NONE=y
# BR2_PACKAGE_BUSYBOX is not set
BR2_PACKAGE_QT=y
# BR2_PACKAGE_QT_XML is not set
# BR2_TARGET_ROOTFS_TAR is not set
EOF
$ make olddefconfig
$ make
Comment 3 Giulio Benetti 2020-02-28 17:44:16 UTC
This issue still exists with version 2.31.1 when building protobuf on OpenRisc:

/home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: BFD (GNU Binutils) 2.31.1 assertion fail elf32-or1k.c:1752
collect2: error: ld returned 1 exit status
make[4]: *** [Makefile:2694: libprotobuf-lite.la] Error 1
make[4]: *** Waiting for unfinished jobs....
/home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: /home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/crtbeginS.o: in function `deregister_tm_clones':
crtstuff.c:(.text+0x48): relocation truncated to fit: R_OR1K_GOT16 against undefined symbol `_ITM_deregisterTMCloneTable'
/home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: /home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/crtbeginS.o: in function `register_tm_clones':
crtstuff.c:(.text+0xd8): relocation truncated to fit: R_OR1K_GOT16 against undefined symbol `_ITM_registerTMCloneTable'
/home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: /home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/crtbeginS.o: in function `__do_global_dtors_aux':
crtstuff.c:(.text+0x158): relocation truncated to fit: R_OR1K_GOT16 against symbol `__cxa_finalize' defined in .text section in /home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/or1k-buildroot-linux-uclibc/sysroot/lib/libc.so.1
/home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: crtstuff.c:(.text+0x1e0): relocation truncated to fit: R_OR1K_GOT16 against symbol `__deregister_frame_info@@GLIBC_2.0' defined in .text section in /home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/lib/libgcc_s.so
/home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: /home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/crtbeginS.o: in function `frame_dummy':
crtstuff.c:(.text+0x278): relocation truncated to fit: R_OR1K_GOT16 against symbol `__register_frame_info@@GLIBC_2.0' defined in .text section in /home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/lib/libgcc_s.so
/home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: crtstuff.c:(.text+0x2c0): relocation truncated to fit: R_OR1K_GOT16 against undefined symbol `_Jv_RegisterClasses'
/home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: google/protobuf/stubs/.libs/bytestream.o: in function `google::protobuf::strings::CheckedArrayByteSink::CheckedArrayByteSink(char*, unsigned int)':
bytestream.cc:(.text+0x3bc): relocation truncated to fit: R_OR1K_GOT16 against symbol `vtable for google::protobuf::strings::CheckedArrayByteSink' defined in .data.rel.ro._ZTVN6google8protobuf7strings20CheckedArrayByteSinkE[_ZTVN6google8protobuf7strings20CheckedArrayByteSinkE] section in google/protobuf/stubs/.libs/bytestream.o
/home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: google/protobuf/stubs/.libs/bytestream.o: in function `google::protobuf::strings::GrowingArrayByteSink::GrowingArrayByteSink(unsigned int)':
bytestream.cc:(.text+0x668): relocation truncated to fit: R_OR1K_GOT16 against symbol `vtable for google::protobuf::strings::GrowingArrayByteSink' defined in .data.rel.ro._ZTVN6google8protobuf7strings20GrowingArrayByteSinkE[_ZTVN6google8protobuf7strings20GrowingArrayByteSinkE] section in google/protobuf/stubs/.libs/bytestream.o
/home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: google/protobuf/stubs/.libs/bytestream.o: in function `google::protobuf::strings::GrowingArrayByteSink::~GrowingArrayByteSink()':
bytestream.cc:(.text+0x714): relocation truncated to fit: R_OR1K_GOT16 against symbol `vtable for google::protobuf::strings::GrowingArrayByteSink' defined in .data.rel.ro._ZTVN6google8protobuf7strings20GrowingArrayByteSinkE[_ZTVN6google8protobuf7strings20GrowingArrayByteSinkE] section in google/protobuf/stubs/.libs/bytestream.o
/home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: google/protobuf/stubs/.libs/bytestream.o: in function `google::protobuf::strings::LimitByteSource::LimitByteSource(google::protobuf::strings::ByteSource*, unsigned int)':
bytestream.cc:(.text+0xf3c): relocation truncated to fit: R_OR1K_GOT16 against symbol `vtable for google::protobuf::strings::LimitByteSource' defined in .data.rel.ro._ZTVN6google8protobuf7strings15LimitByteSourceE[_ZTVN6google8protobuf7strings15LimitByteSourceE] section in google/protobuf/stubs/.libs/bytestream.o
/home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: google/protobuf/stubs/.libs/bytestream.o: in function `__static_initialization_and_destruction_0(int, int)':
bytestream.cc:(.text+0x1444): additional relocation overflows omitted from the output
/home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: BFD (GNU Binutils) 2.31.1 assertion fail elf32-or1k.c:1752
/home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: BFD (GNU Binutils) 2.31.1 assertion fail elf32-or1k.c:1752
/home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: BFD (GNU Binutils) 2.31.1 assertion fail elf32-or1k.c:1752
collect2: error: ld returned 1 exit status
make[4]: *** [Makefile:2847: libprotobuf.la] Error 1
make[3]: *** [Makefile:1733: all-recursive] Error 1
make[2]: *** [Makefile:1640: all] Error 2
make[1]: *** [package/pkg-generic.mk:274: /home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/build/protobuf-3.11.0/.stamp_built] Error 2
make: *** [Makefile:23: _all] Error 2

This issue can be reproduced using the following steps:

o reproduce it:

# git clone git://git.busybox.net/buildroot
# wget https://git.busybox.net/buildroot-test/tree/utils/br-reproduce-build

- modify BASE_GIT=... with your buildroot path in br-reproduce-build then:
# chmod a+x br-reproduce-build
# ./br-reproduce-build 9084cd777aefe0fa8235514c33767d8640ad7a5b

Can't still find a workaround.
Comment 4 Nick Clifton 2020-03-04 10:47:38 UTC
Hi Thomas,

  I tried to reproduce this problem using the latest development binutils
  sources.  I may have misconfigured the linker, but when I used it, I
  encountered this error:

ld: /home/nickc/work/sources/delme/9084cd777aefe0fa8235514c33767d8640ad7a5b/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/crtbeginS.o: addend should be zero for plt relocations

  Does this seem to be a likely problem, or am I using a bad configuration ?
  (If the latter, please can you let me know the correct configuration).

Cheers
  Nick
Comment 5 Giulio Benetti 2021-03-17 21:31:59 UTC
Hi Nick,

this bug still shows up with binutils 2.36.1 like:
/home/giuliobenetti/git/upstream/or1k-binutils-2.36.1/host/lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: BFD (GNU Binutils) 2.36.1 assertion fail elf32-or1k.c:2377
/home/giuliobenetti/git/upstream/or1k-binutils-2.36.1/host/lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: BFD (GNU Binutils) 2.36.1 assertion fail elf32-or1k.c:2377
/home/giuliobenetti/git/upstream/or1k-binutils-2.36.1/host/lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: BFD (GNU Binutils) 2.36.1 assertion fail elf32-or1k.c:2377
collect2: error: ld returned 1 exit status

To reproduce it:
# git clone git://git.busybox.net/buildroot
# wget https://git.busybox.net/buildroot-test/tree/utils/br-reproduce-build

- modify BASE_GIT=... with your buildroot path in br-reproduce-build then:
# chmod a+x br-reproduce-build
# ./br-reproduce-build 6c87be004adf03955c832be72c0c59749f311f71

And I still can't find a workaround.

Do you have any idea to fix this?

Thank you
Comment 6 Stafford Horne 2021-03-17 22:10:13 UTC
On Wed, Mar 17, 2021 at 09:31:59PM +0000, giulio.benetti at micronovasrl dot com wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=21464
> 
> --- Comment #5 from Giulio Benetti <giulio.benetti at micronovasrl dot com> ---
> Hi Nick,
> 
> this bug still shows up with binutils 2.36.1 like:
> /home/giuliobenetti/git/upstream/or1k-binutils-2.36.1/host/lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld:
> BFD (GNU Binutils) 2.36.1 assertion fail elf32-or1k.c:2377
> /home/giuliobenetti/git/upstream/or1k-binutils-2.36.1/host/lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld:
> BFD (GNU Binutils) 2.36.1 assertion fail elf32-or1k.c:2377
> /home/giuliobenetti/git/upstream/or1k-binutils-2.36.1/host/lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld:
> BFD (GNU Binutils) 2.36.1 assertion fail elf32-or1k.c:2377
> collect2: error: ld returned 1 exit status
> 
> To reproduce it:
> # git clone git://git.busybox.net/buildroot
> # wget https://git.busybox.net/buildroot-test/tree/utils/br-reproduce-build
> 
> - modify BASE_GIT=... with your buildroot path in br-reproduce-build then:
> # chmod a+x br-reproduce-build
> # ./br-reproduce-build 6c87be004adf03955c832be72c0c59749f311f71
> 
> And I still can't find a workaround.
> 
> Do you have any idea to fix this?

Hello,

Sorry I missed the first mail.  At first look I don't know how to fix this.

I will have a look, I spent some time last year fixing many bugs with the
or1k linker code pointed out by glibc testing.  Those fixes are all upstream
now.  I didn't see this one before.

I will look at it.

For my reference:

  https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=bfd/elf32-or1k.c;h=65938e51378d2c68b60769ba7d6f5443f18bea5d;hb=HEAD#l2377

2347 static bfd_boolean
2348 or1k_elf_finish_dynamic_symbol (bfd *output_bfd,
2349                                 struct bfd_link_info *info,
2350                                 struct elf_link_hash_entry *h,
2351                                 Elf_Internal_Sym *sym)
2352 {
2353   struct elf_or1k_link_hash_table *htab;
2354   bfd_byte *loc;
2355 
2356   htab = or1k_elf_hash_table (info);
2357   if (htab == NULL)
2358     return FALSE;
2359 
2360   if (h->plt.offset != (bfd_vma) -1)
2361     {
2362       unsigned int plt0, plt1, plt2;
2363       asection *splt;
2364       asection *sgot;
2365       asection *srela;
2366       bfd_vma plt_base_addr;
2367       bfd_vma plt_addr;
2368       bfd_vma plt_index;
2369       bfd_vma plt_reloc;
2370       bfd_vma got_base_addr;
2371       bfd_vma got_offset;
2372       bfd_vma got_addr;
2373       Elf_Internal_Rela rela;
2374 
2375       /* This symbol has an entry in the procedure linkage table.  Set
2376          it up.  */
2377       BFD_ASSERT (h->dynindx != -1);

My Docs:

http://stffrdhrn.github.io/software/toolchain/openrisc/2020/07/21/relocs_tls_impl.html#phase-4---finishing-up-finish_dynamic_symbol--finish_dynamic_sections

Notes:

https://gist.github.com/stffrdhrn/d59e1d082430a48643b301c13f6f4d24

bfd/elflink.c
  bfd_elf_gc_common_final_link
    - bfd_elf_gc_common_finalize_got_offsets - local_got.offsets setup
  bfd_elf_final_link()
  - elf_link_input_bfd
    - or1k_elf_relocate_section      - BFD API, P3 main worker writes to
      sections
  - travers(elf_link_output_extsym) - called 2 times
    - or1k_elf_finish_dynamic_symbol - BFD API, P4 for a symbol write to .plt,
      .got + .got.rela
  - or1k_elf_finish_dynamic_sections - BFD API, P4 add final things to .plt, etc


-Stafford
Comment 7 Stafford Horne 2021-03-21 03:00:50 UTC
On Wed, Mar 17, 2021 at 10:10:13PM +0000, shorne at gmail dot com wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=21464
> 
> --- Comment #6 from Stafford Horne <shorne at gmail dot com> ---
> On Wed, Mar 17, 2021 at 09:31:59PM +0000, giulio.benetti at micronovasrl dot
> com wrote:
> > https://sourceware.org/bugzilla/show_bug.cgi?id=21464
> > 
> > --- Comment #5 from Giulio Benetti <giulio.benetti at micronovasrl dot com> ---
> > Hi Nick,
> > 
> > this bug still shows up with binutils 2.36.1 like:
> > /home/giuliobenetti/git/upstream/or1k-binutils-2.36.1/host/lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld:
> > BFD (GNU Binutils) 2.36.1 assertion fail elf32-or1k.c:2377
> > /home/giuliobenetti/git/upstream/or1k-binutils-2.36.1/host/lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld:
> > BFD (GNU Binutils) 2.36.1 assertion fail elf32-or1k.c:2377
> > /home/giuliobenetti/git/upstream/or1k-binutils-2.36.1/host/lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld:
> > BFD (GNU Binutils) 2.36.1 assertion fail elf32-or1k.c:2377
> > collect2: error: ld returned 1 exit status
> > 

Hello,

I was able to reproduce the "assertion fail elf32-or1k.c:2377" issue with my
latest glibc toolchain versions, and I also did some debugging of LD to try to
get an idea of what is going on.

Reproduced with:
  - Just building protobuf on its own, not using buildroot, that was giving me
    some exceptions about not being able to find a thread librarty.

Notes

1. The "relocation truncated to fit: R_OR1K_GOT16" error seems not be outputted
   in the latest LD.  I maybe have removed it incorrectly with some recent changes?  The
   issue is not fixed.  The R_OR1K_GOT16 relocation limit means OpenRISC fails to
   run some PLT entries at run time when there are too many symbols.  I am planning
   to fix this.

   I have two ideas:
    1. When we get to big plt entries over the limit will use 2 relocations to
       compose the GOT offset
    2. Use an extra PLT trampoline entry to add the extra offset i.e. 16k
       When we go over 32k we have another trampoline, that adds 16k and jumps to
      the previous trampoline.

2. The "assertion fail elf32-or1k.c:2377" seems to be something different to me,
   and not related to the count of GOT entries, maybe it should be a different bug issue?

3. When debugging the "assertion fail elf32-or1k.c:2377" I see, the line we are failing on is:

       Breakpoint 1, or1k_elf_finish_dynamic_symbol (output_bfd=0x568460, info=0x543320 <link_info>, h=0x81c0f8, sym=0x7fffffffb260) at /home/shorne/work/gnu-toolchain/binutils-gdb/bfd/elf32-or1k.c:2377
       2377          BFD_ASSERT (h->dynindx != -1);

   So, it's asserting that the dynindx is defined, in or1k_elf_finish_dynamic_symbol before
   we write out the PLT entry.

   In the failure cases we see:

       h->root.type bfd_link_hash_defweak AND h->forced_local

   These failing symbols have been forced_local but we are still trying to write the PLT entry.
   That doesn't seem to make much sense.

   The forced_local has been set in _bfd_elf_link_hash_hide_symbol(), the generic
   elflink code:

      #0  _bfd_elf_link_hash_hide_symbol (info=0x543320 <link_info>, h=0x2bcbeb8, force_local=1) at /home/shorne/work/gnu-toolchain/binutils-gdb/bfd/elflink.c:7756
      #1  0x000000000045e61e in _bfd_elf_link_assign_sym_version (h=0x2bcbeb8, data=0x7fffffffb2f0) at /home/shorne/work/gnu-toolchain/binutils-gdb/bfd/elflink.c:2483
      #2  0x000000000043055d in bfd_link_hash_traverse (htab=0x56a790, func=func@entry=0x45e33d <_bfd_elf_link_assign_sym_version>, info=info@entry=0x7fffffffb2f0)

   I tried to look at other architectures and I see that most do the same assert, so
   so would they also fail?

   In riscv (a relatively modern implementation) they seem to just detect this case and return FALSE.
   I will try to do that and send a patch, but it will be hard to test.

   Any suggestion for a test case for this?

-Stafford
Comment 8 Giulio Benetti 2021-03-21 18:09:09 UTC
Hi Stafford,

Il 21/03/2021 04:00, shorne at gmail dot com ha scritto:
> https://sourceware.org/bugzilla/show_bug.cgi?id=21464
> 
> --- Comment #7 from Stafford Horne <shorne at gmail dot com> ---
> On Wed, Mar 17, 2021 at 10:10:13PM +0000, shorne at gmail dot com wrote:
>> https://sourceware.org/bugzilla/show_bug.cgi?id=21464
>>
>> --- Comment #6 from Stafford Horne <shorne at gmail dot com> ---
>> On Wed, Mar 17, 2021 at 09:31:59PM +0000, giulio.benetti at micronovasrl dot
>> com wrote:
>>> https://sourceware.org/bugzilla/show_bug.cgi?id=21464
>>>
>>> --- Comment #5 from Giulio Benetti <giulio.benetti at micronovasrl dot com> ---
>>> Hi Nick,
>>>
>>> this bug still shows up with binutils 2.36.1 like:
>>> /home/giuliobenetti/git/upstream/or1k-binutils-2.36.1/host/lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld:
>>> BFD (GNU Binutils) 2.36.1 assertion fail elf32-or1k.c:2377
>>> /home/giuliobenetti/git/upstream/or1k-binutils-2.36.1/host/lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld:
>>> BFD (GNU Binutils) 2.36.1 assertion fail elf32-or1k.c:2377
>>> /home/giuliobenetti/git/upstream/or1k-binutils-2.36.1/host/lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld:
>>> BFD (GNU Binutils) 2.36.1 assertion fail elf32-or1k.c:2377
>>> collect2: error: ld returned 1 exit status
>>>
> 
> Hello,
> 
> I was able to reproduce the "assertion fail elf32-or1k.c:2377" issue with my
> latest glibc toolchain versions, and I also did some debugging of LD to try to
> get an idea of what is going on.
> 
> Reproduced with:
>    - Just building protobuf on its own, not using buildroot, that was giving me
>      some exceptions about not being able to find a thread librarty.
> 
> Notes
> 
> 1. The "relocation truncated to fit: R_OR1K_GOT16" error seems not be outputted
>     in the latest LD.  I maybe have removed it incorrectly with some recent
> changes?  The
>     issue is not fixed.  The R_OR1K_GOT16 relocation limit means OpenRISC fails
> to
>     run some PLT entries at run time when there are too many symbols.  I am
> planning
>     to fix this.

It seems to be the same bug since it fails on assert(), but maybe I'm wrong.

>     I have two ideas:
>      1. When we get to big plt entries over the limit will use 2 relocations to
>         compose the GOT offset
>      2. Use an extra PLT trampoline entry to add the extra offset i.e. 16k
>         When we go over 32k we have another trampoline, that adds 16k and jumps
> to
>        the previous trampoline.
> 
> 2. The "assertion fail elf32-or1k.c:2377" seems to be something different to
> me,
>     and not related to the count of GOT entries, maybe it should be a different
> bug issue?

Yes, it seems since...

> 3. When debugging the "assertion fail elf32-or1k.c:2377" I see, the line we are
> failing on is:
> 
>         Breakpoint 1, or1k_elf_finish_dynamic_symbol (output_bfd=0x568460,
> info=0x543320 <link_info>, h=0x81c0f8, sym=0x7fffffffb260) at
> /home/shorne/work/gnu-toolchain/binutils-gdb/bfd/elf32-or1k.c:2377
>         2377          BFD_ASSERT (h->dynindx != -1);
> 
>     So, it's asserting that the dynindx is defined, in
> or1k_elf_finish_dynamic_symbol before
>     we write out the PLT entry.
> 
>     In the failure cases we see:
> 
>         h->root.type bfd_link_hash_defweak AND h->forced_local
> 
>     These failing symbols have been forced_local but we are still trying to
> write the PLT entry.
>     That doesn't seem to make much sense.
> 
>     The forced_local has been set in _bfd_elf_link_hash_hide_symbol(), the
> generic
>     elflink code:
> 
>        #0  _bfd_elf_link_hash_hide_symbol (info=0x543320 <link_info>,
> h=0x2bcbeb8, force_local=1) at
> /home/shorne/work/gnu-toolchain/binutils-gdb/bfd/elflink.c:7756
>        #1  0x000000000045e61e in _bfd_elf_link_assign_sym_version (h=0x2bcbeb8,
> data=0x7fffffffb2f0) at
> /home/shorne/work/gnu-toolchain/binutils-gdb/bfd/elflink.c:2483
>        #2  0x000000000043055d in bfd_link_hash_traverse (htab=0x56a790,
> func=func@entry=0x45e33d <_bfd_elf_link_assign_sym_version>,
> info=info@entry=0x7fffffffb2f0)
> 
>     I tried to look at other architectures and I see that most do the same
> assert, so
>     so would they also fail?
> 
>     In riscv (a relatively modern implementation) they seem to just detect this
> case and return FALSE.
>     I will try to do that and send a patch, but it will be hard to test.

I've tried to imitate what riscv does:
'''
diff --git a/bfd/elf32-or1k.c b/bfd/elf32-or1k.c
index 65938e5137..74cff4bf01 100644
--- a/bfd/elf32-or1k.c
+++ b/bfd/elf32-or1k.c
@@ -2372,15 +2372,22 @@ or1k_elf_finish_dynamic_symbol (bfd *output_bfd,
        bfd_vma got_addr;
        Elf_Internal_Rela rela;

-      /* This symbol has an entry in the procedure linkage table.  Set
-        it up.  */
-      BFD_ASSERT (h->dynindx != -1);
-
        splt = htab->root.splt;
        sgot = htab->root.sgotplt;
        srela = htab->root.srelplt;
        BFD_ASSERT (splt != NULL && sgot != NULL && srela != NULL);

+      /* This symbol has an entry in the procedure linkage table.  Set
+        it up.  */
+      if ((h->dynindx == -1
+           && !((h->forced_local || bfd_link_executable (info))
+                && h->def_regular
+                && h->type == STT_GNU_IFUNC))
+          || splt == NULL
+          || sgot == NULL
+          || srela == NULL)
+        return FALSE;
+
        plt_base_addr = splt->output_section->vma + splt->output_offset;
        got_base_addr = sgot->output_section->vma + sgot->output_offset;

--
'''

but it still fails and without emitting anything, only:
collect2: error: ld returned 1 exit status

>     Any suggestion for a test case for this?
> 
> -Stafford
> 

Another package that has the same problem is libtheora

I don't know how to help you more.
Tell me if you need something else

Kind regards
Comment 9 Stafford Horne 2021-03-21 21:29:22 UTC
On Sun, Mar 21, 2021 at 06:09:09PM +0000, giulio.benetti at micronovasrl dot com wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=21464
> 
> --- Comment #8 from Giulio Benetti <giulio.benetti at micronovasrl dot com> ---
> Hi Stafford,
> 
> Il 21/03/2021 04:00, shorne at gmail dot com ha scritto:
> > https://sourceware.org/bugzilla/show_bug.cgi?id=21464
> > 
> > --- Comment #7 from Stafford Horne <shorne at gmail dot com> ---
> > On Wed, Mar 17, 2021 at 10:10:13PM +0000, shorne at gmail dot com wrote:
> >> https://sourceware.org/bugzilla/show_bug.cgi?id=21464
> >>
> >> --- Comment #6 from Stafford Horne <shorne at gmail dot com> ---
> >> On Wed, Mar 17, 2021 at 09:31:59PM +0000, giulio.benetti at micronovasrl dot
> >> com wrote:
> >>> https://sourceware.org/bugzilla/show_bug.cgi?id=21464
> >>>
> >>> --- Comment #5 from Giulio Benetti <giulio.benetti at micronovasrl dot com> ---
> >>> Hi Nick,
> >>>
> >>> this bug still shows up with binutils 2.36.1 like:
> >>> /home/giuliobenetti/git/upstream/or1k-binutils-2.36.1/host/lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld:
> >>> BFD (GNU Binutils) 2.36.1 assertion fail elf32-or1k.c:2377
> >>> /home/giuliobenetti/git/upstream/or1k-binutils-2.36.1/host/lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld:
> >>> BFD (GNU Binutils) 2.36.1 assertion fail elf32-or1k.c:2377
> >>> /home/giuliobenetti/git/upstream/or1k-binutils-2.36.1/host/lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld:
> >>> BFD (GNU Binutils) 2.36.1 assertion fail elf32-or1k.c:2377
> >>> collect2: error: ld returned 1 exit status
> >>>
> > 
> > Hello,
> > 
> > I was able to reproduce the "assertion fail elf32-or1k.c:2377" issue with my
> > latest glibc toolchain versions, and I also did some debugging of LD to try to
> > get an idea of what is going on.
> > 
> > Reproduced with:
> >    - Just building protobuf on its own, not using buildroot, that was giving me
> >      some exceptions about not being able to find a thread librarty.
> > 
> > Notes
> > 
> > 1. The "relocation truncated to fit: R_OR1K_GOT16" error seems not be outputted
> >     in the latest LD.  I maybe have removed it incorrectly with some recent
> > changes?  The
> >     issue is not fixed.  The R_OR1K_GOT16 relocation limit means OpenRISC fails
> > to
> >     run some PLT entries at run time when there are too many symbols.  I am
> > planning
> >     to fix this.
> 
> It seems to be the same bug since it fails on assert(), but maybe I'm wrong.
> 
> >     I have two ideas:
> >      1. When we get to big plt entries over the limit will use 2 relocations to
> >         compose the GOT offset
> >      2. Use an extra PLT trampoline entry to add the extra offset i.e. 16k
> >         When we go over 32k we have another trampoline, that adds 16k and jumps
> > to
> >        the previous trampoline.
> > 
> > 2. The "assertion fail elf32-or1k.c:2377" seems to be something different to
> > me,
> >     and not related to the count of GOT entries, maybe it should be a different
> > bug issue?
> 
> Yes, it seems since...
> 
> > 3. When debugging the "assertion fail elf32-or1k.c:2377" I see, the line we are
> > failing on is:
> > 
> >         Breakpoint 1, or1k_elf_finish_dynamic_symbol (output_bfd=0x568460,
> > info=0x543320 <link_info>, h=0x81c0f8, sym=0x7fffffffb260) at
> > /home/shorne/work/gnu-toolchain/binutils-gdb/bfd/elf32-or1k.c:2377
> >         2377          BFD_ASSERT (h->dynindx != -1);
> > 
> >     So, it's asserting that the dynindx is defined, in
> > or1k_elf_finish_dynamic_symbol before
> >     we write out the PLT entry.
> > 
> >     In the failure cases we see:
> > 
> >         h->root.type bfd_link_hash_defweak AND h->forced_local
> > 
> >     These failing symbols have been forced_local but we are still trying to
> > write the PLT entry.
> >     That doesn't seem to make much sense.
> > 
> >     The forced_local has been set in _bfd_elf_link_hash_hide_symbol(), the
> > generic
> >     elflink code:
> > 
> >        #0  _bfd_elf_link_hash_hide_symbol (info=0x543320 <link_info>,
> > h=0x2bcbeb8, force_local=1) at
> > /home/shorne/work/gnu-toolchain/binutils-gdb/bfd/elflink.c:7756
> >        #1  0x000000000045e61e in _bfd_elf_link_assign_sym_version (h=0x2bcbeb8,
> > data=0x7fffffffb2f0) at
> > /home/shorne/work/gnu-toolchain/binutils-gdb/bfd/elflink.c:2483
> >        #2  0x000000000043055d in bfd_link_hash_traverse (htab=0x56a790,
> > func=func@entry=0x45e33d <_bfd_elf_link_assign_sym_version>,
> > info=info@entry=0x7fffffffb2f0)
> > 
> >     I tried to look at other architectures and I see that most do the same
> > assert, so
> >     so would they also fail?
> > 
> >     In riscv (a relatively modern implementation) they seem to just detect this
> > case and return FALSE.
> >     I will try to do that and send a patch, but it will be hard to test.
> 
> I've tried to imitate what riscv does:
> '''
> diff --git a/bfd/elf32-or1k.c b/bfd/elf32-or1k.c
> index 65938e5137..74cff4bf01 100644
> --- a/bfd/elf32-or1k.c
> +++ b/bfd/elf32-or1k.c
> @@ -2372,15 +2372,22 @@ or1k_elf_finish_dynamic_symbol (bfd *output_bfd,
>         bfd_vma got_addr;
>         Elf_Internal_Rela rela;
> 
> -      /* This symbol has an entry in the procedure linkage table.  Set
> -        it up.  */
> -      BFD_ASSERT (h->dynindx != -1);
> -
>         splt = htab->root.splt;
>         sgot = htab->root.sgotplt;
>         srela = htab->root.srelplt;
>         BFD_ASSERT (splt != NULL && sgot != NULL && srela != NULL);
> 
> +      /* This symbol has an entry in the procedure linkage table.  Set
> +        it up.  */
> +      if ((h->dynindx == -1
> +           && !((h->forced_local || bfd_link_executable (info))
> +                && h->def_regular
> +                && h->type == STT_GNU_IFUNC))
> +          || splt == NULL
> +          || sgot == NULL
> +          || srela == NULL)
> +        return FALSE;
> +
>         plt_base_addr = splt->output_section->vma + splt->output_offset;
>         got_base_addr = sgot->output_section->vma + sgot->output_offset;
> 
> --
> '''
> 
> but it still fails and without emitting anything, only:
> collect2: error: ld returned 1 exit status
> 
> >     Any suggestion for a test case for this?
> > 

I did some more investigation about why we are actually calling the dynamic
finishup code for these symbols.

I found some other code that might help...

diff --git a/bfd/elf32-or1k.c b/bfd/elf32-or1k.c
index 38406eda3d6..f1cfed230a1 100644
--- a/bfd/elf32-or1k.c
+++ b/bfd/elf32-or1k.c
@@ -2566,11 +2566,10 @@ or1k_elf_adjust_dynamic_symbol (struct bfd_link_info
*info,
   if (h->type == STT_FUNC
       || h->needs_plt)
     {
-      if (! bfd_link_pic (info)
-         && !h->def_dynamic
-         && !h->ref_dynamic
-         && h->root.type != bfd_link_hash_undefweak
-         && h->root.type != bfd_link_hash_undefined)
+      if (h->plt.refcount <= 0
+         || (SYMBOL_CALLS_LOCAL (info, h)
+         || (ELF_ST_VISIBILITY (h->other) != STV_DEFAULT
+             && h->root.type == bfd_link_hash_undefweak)))
        {
          /* This case can occur if we saw a PLT reloc in an input
             file, but the symbol was never referred to by a dynamic

--

With this patch we skip the PLT calls once we determine they have been "forced
local".  It seems to work.

-Stafford
Comment 10 Giulio Benetti 2021-03-22 13:15:28 UTC
Il 21/03/2021 22:29, shorne at gmail dot com ha scritto:
> https://sourceware.org/bugzilla/show_bug.cgi?id=21464
> 
> --- Comment #9 from Stafford Horne <shorne at gmail dot com> ---
> On Sun, Mar 21, 2021 at 06:09:09PM +0000, giulio.benetti at micronovasrl dot
> com wrote:
>> https://sourceware.org/bugzilla/show_bug.cgi?id=21464
>>
>> --- Comment #8 from Giulio Benetti <giulio.benetti at micronovasrl dot com> ---
>> Hi Stafford,
>>
>> Il 21/03/2021 04:00, shorne at gmail dot com ha scritto:
>>> https://sourceware.org/bugzilla/show_bug.cgi?id=21464
>>>
>>> --- Comment #7 from Stafford Horne <shorne at gmail dot com> ---
>>> On Wed, Mar 17, 2021 at 10:10:13PM +0000, shorne at gmail dot com wrote:
>>>> https://sourceware.org/bugzilla/show_bug.cgi?id=21464
>>>>
>>>> --- Comment #6 from Stafford Horne <shorne at gmail dot com> ---
>>>> On Wed, Mar 17, 2021 at 09:31:59PM +0000, giulio.benetti at micronovasrl dot
>>>> com wrote:
>>>>> https://sourceware.org/bugzilla/show_bug.cgi?id=21464
>>>>>
>>>>> --- Comment #5 from Giulio Benetti <giulio.benetti at micronovasrl dot com> ---
>>>>> Hi Nick,
>>>>>
>>>>> this bug still shows up with binutils 2.36.1 like:
>>>>> /home/giuliobenetti/git/upstream/or1k-binutils-2.36.1/host/lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld:
>>>>> BFD (GNU Binutils) 2.36.1 assertion fail elf32-or1k.c:2377
>>>>> /home/giuliobenetti/git/upstream/or1k-binutils-2.36.1/host/lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld:
>>>>> BFD (GNU Binutils) 2.36.1 assertion fail elf32-or1k.c:2377
>>>>> /home/giuliobenetti/git/upstream/or1k-binutils-2.36.1/host/lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld:
>>>>> BFD (GNU Binutils) 2.36.1 assertion fail elf32-or1k.c:2377
>>>>> collect2: error: ld returned 1 exit status
>>>>>
>>>
>>> Hello,
>>>
>>> I was able to reproduce the "assertion fail elf32-or1k.c:2377" issue with my
>>> latest glibc toolchain versions, and I also did some debugging of LD to try to
>>> get an idea of what is going on.
>>>
>>> Reproduced with:
>>>     - Just building protobuf on its own, not using buildroot, that was giving me
>>>       some exceptions about not being able to find a thread librarty.
>>>
>>> Notes
>>>
>>> 1. The "relocation truncated to fit: R_OR1K_GOT16" error seems not be outputted
>>>      in the latest LD.  I maybe have removed it incorrectly with some recent
>>> changes?  The
>>>      issue is not fixed.  The R_OR1K_GOT16 relocation limit means OpenRISC fails
>>> to
>>>      run some PLT entries at run time when there are too many symbols.  I am
>>> planning
>>>      to fix this.
>>
>> It seems to be the same bug since it fails on assert(), but maybe I'm wrong.
>>
>>>      I have two ideas:
>>>       1. When we get to big plt entries over the limit will use 2 relocations to
>>>          compose the GOT offset
>>>       2. Use an extra PLT trampoline entry to add the extra offset i.e. 16k
>>>          When we go over 32k we have another trampoline, that adds 16k and jumps
>>> to
>>>         the previous trampoline.
>>>
>>> 2. The "assertion fail elf32-or1k.c:2377" seems to be something different to
>>> me,
>>>      and not related to the count of GOT entries, maybe it should be a different
>>> bug issue?
>>
>> Yes, it seems since...
>>
>>> 3. When debugging the "assertion fail elf32-or1k.c:2377" I see, the line we are
>>> failing on is:
>>>
>>>          Breakpoint 1, or1k_elf_finish_dynamic_symbol (output_bfd=0x568460,
>>> info=0x543320 <link_info>, h=0x81c0f8, sym=0x7fffffffb260) at
>>> /home/shorne/work/gnu-toolchain/binutils-gdb/bfd/elf32-or1k.c:2377
>>>          2377          BFD_ASSERT (h->dynindx != -1);
>>>
>>>      So, it's asserting that the dynindx is defined, in
>>> or1k_elf_finish_dynamic_symbol before
>>>      we write out the PLT entry.
>>>
>>>      In the failure cases we see:
>>>
>>>          h->root.type bfd_link_hash_defweak AND h->forced_local
>>>
>>>      These failing symbols have been forced_local but we are still trying to
>>> write the PLT entry.
>>>      That doesn't seem to make much sense.
>>>
>>>      The forced_local has been set in _bfd_elf_link_hash_hide_symbol(), the
>>> generic
>>>      elflink code:
>>>
>>>         #0  _bfd_elf_link_hash_hide_symbol (info=0x543320 <link_info>,
>>> h=0x2bcbeb8, force_local=1) at
>>> /home/shorne/work/gnu-toolchain/binutils-gdb/bfd/elflink.c:7756
>>>         #1  0x000000000045e61e in _bfd_elf_link_assign_sym_version (h=0x2bcbeb8,
>>> data=0x7fffffffb2f0) at
>>> /home/shorne/work/gnu-toolchain/binutils-gdb/bfd/elflink.c:2483
>>>         #2  0x000000000043055d in bfd_link_hash_traverse (htab=0x56a790,
>>> func=func@entry=0x45e33d <_bfd_elf_link_assign_sym_version>,
>>> info=info@entry=0x7fffffffb2f0)
>>>
>>>      I tried to look at other architectures and I see that most do the same
>>> assert, so
>>>      so would they also fail?
>>>
>>>      In riscv (a relatively modern implementation) they seem to just detect this
>>> case and return FALSE.
>>>      I will try to do that and send a patch, but it will be hard to test.
>>
>> I've tried to imitate what riscv does:
>> '''
>> diff --git a/bfd/elf32-or1k.c b/bfd/elf32-or1k.c
>> index 65938e5137..74cff4bf01 100644
>> --- a/bfd/elf32-or1k.c
>> +++ b/bfd/elf32-or1k.c
>> @@ -2372,15 +2372,22 @@ or1k_elf_finish_dynamic_symbol (bfd *output_bfd,
>>          bfd_vma got_addr;
>>          Elf_Internal_Rela rela;
>>
>> -      /* This symbol has an entry in the procedure linkage table.  Set
>> -        it up.  */
>> -      BFD_ASSERT (h->dynindx != -1);
>> -
>>          splt = htab->root.splt;
>>          sgot = htab->root.sgotplt;
>>          srela = htab->root.srelplt;
>>          BFD_ASSERT (splt != NULL && sgot != NULL && srela != NULL);
>>
>> +      /* This symbol has an entry in the procedure linkage table.  Set
>> +        it up.  */
>> +      if ((h->dynindx == -1
>> +           && !((h->forced_local || bfd_link_executable (info))
>> +                && h->def_regular
>> +                && h->type == STT_GNU_IFUNC))
>> +          || splt == NULL
>> +          || sgot == NULL
>> +          || srela == NULL)
>> +        return FALSE;
>> +
>>          plt_base_addr = splt->output_section->vma + splt->output_offset;
>>          got_base_addr = sgot->output_section->vma + sgot->output_offset;
>>
>> --
>> '''
>>
>> but it still fails and without emitting anything, only:
>> collect2: error: ld returned 1 exit status
>>
>>>      Any suggestion for a test case for this?
>>>
> 
> I did some more investigation about why we are actually calling the dynamic
> finishup code for these symbols.
> 
> I found some other code that might help...
> 
> diff --git a/bfd/elf32-or1k.c b/bfd/elf32-or1k.c
> index 38406eda3d6..f1cfed230a1 100644
> --- a/bfd/elf32-or1k.c
> +++ b/bfd/elf32-or1k.c
> @@ -2566,11 +2566,10 @@ or1k_elf_adjust_dynamic_symbol (struct bfd_link_info
> *info,
>     if (h->type == STT_FUNC
>         || h->needs_plt)
>       {
> -      if (! bfd_link_pic (info)
> -         && !h->def_dynamic
> -         && !h->ref_dynamic
> -         && h->root.type != bfd_link_hash_undefweak
> -         && h->root.type != bfd_link_hash_undefined)
> +      if (h->plt.refcount <= 0
> +         || (SYMBOL_CALLS_LOCAL (info, h)
> +         || (ELF_ST_VISIBILITY (h->other) != STV_DEFAULT
> +             && h->root.type == bfd_link_hash_undefweak)))
>          {
>            /* This case can occur if we saw a PLT reloc in an input
>               file, but the symbol was never referred to by a dynamic
> 
> --
> 
> With this patch we skip the PLT calls once we determine they have been "forced
> local".  It seems to work.
> 
> -Stafford
> 

Hi Stafford,

thank you for providing such fix, it works with binutils:
- 2.32
- 2.34
- 2.35.2
- 2.36.1

while building these packages:
- protobuf
- libtheora
- zeromq

that were previously failing to link.

Thanks a lot!
Best regards
Giulio Benetti
Comment 11 Giulio Benetti 2021-03-22 15:49:27 UTC
Hi Stafford,

I've given a try to build libgeos and it still doesn't link, but then we're facing 2 different bugs and I've mixed them up.
With libgeos it's true that linker hangs on assert() but before it emits
"relocation truncated to fit: R_OR1K_GOT16 against symbol"

So what you've propose fixes another bug that I'm going to submit.

So I ask you if you can fix the current bug:
relocation truncated to fit: R_OR1K_GOT16 against symbol

Thank you!
Comment 12 Giulio Benetti 2021-03-22 15:53:09 UTC
Stafford, this is the bug you've fixed:
https://sourceware.org/bugzilla/show_bug.cgi?id=27624

So this is still pending.
Comment 13 Stafford Horne 2021-03-22 23:36:10 UTC
Hi Giulio,

What issue are you seeing for geos, I am wondering if it is also something different.  I tried to build it and I see again different issues, not the "relocation truncated to fit: R_OR1K_GOT16 against symbol" issue.

See below for what I see.

Note, I am not sure I am building this correctly and maybe this is an issue with how cmake is passing link arguments to ld.

 # Cross compile setting CXX/CC compilers
 CXX=or1k-smh-linux-gnu-g++ CC=or1k-smh-linux-gnu-gcc cmake ../geos/

 # Need to suppress this warning
 make CXX_FLAGS="$CXX_FLAGS -Wno-error=nonnull" 

 # then I see:

[ 34%] Linking CXX shared library lib/libgeos.so
/home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: pc-relative relocation against dynamic symbol _ZN4geos5index7strtree15AbstractSTRtreeC2Ej
/home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: pc-relative relocation against dynamic symbol _ZN4geos5index12SpatialIndexC2Ev
/home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: non-pic relocation against symbol _ZTVN4geos5index7strtree7STRtreeE
/home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: non-pic relocation against symbol _ZTVN4geos5index7strtree7STRtreeE
/home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: non-pic relocation against symbol _ZTVN4geos5index7strtree7STRtreeE
...
/home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: pc-relative relocation against dynamic symbol _ZNK9__gnu_cxx17__normal_iteratorIPPN4geos5index7strtree9BoundableESt6vectorIS5_SaIS5_EEEdeEv
/home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: pc-relative relocation against dynamic symbol _ZNK9__gnu_cxx17__normal_iteratorIPPN4geos5index7strtree9BoundableESt6vectorIS5_SaIS5_EEEplEi
/home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: pc-relative relocation against dynamic symbol _ZSt4moveIRPN4geos5index7strtree9BoundableEEONSt16remove_referenceIT_E4typeEOS7_
/home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: pc-relative relocation against dynamic symbol _ZNK9__gnu_cxx17__normal_iteratorIPPN4geos5index7strtree9BoundableESt6vectorIS5_SaIS5_EEEplEi
/home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: pc-relative relocation against dynamic symbol _ZNK9__gnu_cxx17__normal_iteratorIPPN4geos5index7strtree9BoundableESt6vectorIS5_SaIS5_EEEdeEv
/home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: pc-relative relocation against dynamic symbol _ZNK9__gnu_cxx17__normal_iteratorIPPN4geos5index7strtree9BoundableESt6vectorIS5_SaIS5_EEEdeEv
/home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: pc-relative relocation against dynamic symbol _ZNK9__gnu_cxx17__normal_iteratorIPPN4geos5index7strtree9BoundableESt6vectorIS5_SaIS5_EEEdeEv
/home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: non-pic relocation against symbol
/home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: non-pic relocation against symbol
/home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: pc-relative relocation against dynamic symbol _ZNSt8ios_base4InitC1Ev@@GLIBCXX_3.4
/home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: non-pic relocation against symbol __dso_handle
/home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: non-pic relocation against symbol __dso_handle
/home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: non-pic relocation against symbol
/home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: non-pic relocation against symbol
/home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: non-pic relocation against symbol _ZNSt8ios_base4InitD1Ev@@GLIBCXX_3.4
/home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: non-pic relocation against symbol _ZNSt8ios_base4InitD1Ev@@GLIBCXX_3.4
/home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: pc-relative relocation against dynamic symbol __cxa_atexit@@GLIBC_2.33
/home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/geos.dir/build.make:5370: lib/libgeos.so.3.10.0dev] Error 1
make[1]: *** [CMakeFiles/Makefile2:1173: CMakeFiles/geos.dir/all] Error 2



readelf -r CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o | grep __dso_handle
000059a4  0006aa23 R_OR1K_AHI16      00000000   __dso_handle + 0
000059a8  0006aa04 R_OR1K_LO_16_IN_I 00000000   __dso_handle + 0


 readelf -r CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o | grep __cxa_atexit
000059bc  0006ac06 R_OR1K_INSN_REL_2 00000000   __cxa_atexit + 0
Comment 14 Giulio Benetti 2021-03-22 23:57:37 UTC
Il 23/03/2021 00:36, shorne at sourceware dot org ha scritto:
> https://sourceware.org/bugzilla/show_bug.cgi?id=21464
> 
> Stafford Horne <shorne at sourceware dot org> changed:
> 
>             What    |Removed                     |Added
> ----------------------------------------------------------------------------
>       Ever confirmed|0                           |1
>             Assignee|unassigned at sourceware dot org   |shorne at sourceware dot org
>     Last reconfirmed|                            |2021-03-22
>               Status|UNCONFIRMED                 |ASSIGNED
> 
> --- Comment #13 from Stafford Horne <shorne at sourceware dot org> ---
> Hi Giulio,
> 
> What issue are you seeing for geos, I am wondering if it is also something
> different.  I tried to build it and I see again different issues, not the
> "relocation truncated to fit: R_OR1K_GOT16 against symbol" issue.
> 
> See below for what I see.
> 
> Note, I am not sure I am building this correctly and maybe this is an issue
> with how cmake is passing link arguments to ld.
> 
>   # Cross compile setting CXX/CC compilers
>   CXX=or1k-smh-linux-gnu-g++ CC=or1k-smh-linux-gnu-gcc cmake ../geos/
> 
>   # Need to suppress this warning
>   make CXX_FLAGS="$CXX_FLAGS -Wno-error=nonnull"
> 
>   # then I see:
> 
> [ 34%] Linking CXX shared library lib/libgeos.so
> /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld:
> CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: pc-relative relocation
> against dynamic symbol _ZN4geos5index7strtree15AbstractSTRtreeC2Ej
> /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld:
> CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: pc-relative relocation
> against dynamic symbol _ZN4geos5index12SpatialIndexC2Ev
> /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld:
> CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: non-pic relocation against
> symbol _ZTVN4geos5index7strtree7STRtreeE
> /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld:
> CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: non-pic relocation against
> symbol _ZTVN4geos5index7strtree7STRtreeE
> /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld:
> CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: non-pic relocation against
> symbol _ZTVN4geos5index7strtree7STRtreeE
> ...
> /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld:
> CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: pc-relative relocation
> against dynamic symbol
> _ZNK9__gnu_cxx17__normal_iteratorIPPN4geos5index7strtree9BoundableESt6vectorIS5_SaIS5_EEEdeEv
> /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld:
> CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: pc-relative relocation
> against dynamic symbol
> _ZNK9__gnu_cxx17__normal_iteratorIPPN4geos5index7strtree9BoundableESt6vectorIS5_SaIS5_EEEplEi
> /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld:
> CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: pc-relative relocation
> against dynamic symbol
> _ZSt4moveIRPN4geos5index7strtree9BoundableEEONSt16remove_referenceIT_E4typeEOS7_
> /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld:
> CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: pc-relative relocation
> against dynamic symbol
> _ZNK9__gnu_cxx17__normal_iteratorIPPN4geos5index7strtree9BoundableESt6vectorIS5_SaIS5_EEEplEi
> /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld:
> CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: pc-relative relocation
> against dynamic symbol
> _ZNK9__gnu_cxx17__normal_iteratorIPPN4geos5index7strtree9BoundableESt6vectorIS5_SaIS5_EEEdeEv
> /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld:
> CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: pc-relative relocation
> against dynamic symbol
> _ZNK9__gnu_cxx17__normal_iteratorIPPN4geos5index7strtree9BoundableESt6vectorIS5_SaIS5_EEEdeEv
> /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld:
> CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: pc-relative relocation
> against dynamic symbol
> _ZNK9__gnu_cxx17__normal_iteratorIPPN4geos5index7strtree9BoundableESt6vectorIS5_SaIS5_EEEdeEv
> /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld:
> CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: non-pic relocation against
> symbol
> /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld:
> CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: non-pic relocation against
> symbol
> /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld:
> CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: pc-relative relocation
> against dynamic symbol _ZNSt8ios_base4InitC1Ev@@GLIBCXX_3.4
> /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld:
> CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: non-pic relocation against
> symbol __dso_handle
> /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld:
> CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: non-pic relocation against
> symbol __dso_handle
> /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld:
> CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: non-pic relocation against
> symbol
> /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld:
> CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: non-pic relocation against
> symbol
> /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld:
> CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: non-pic relocation against
> symbol _ZNSt8ios_base4InitD1Ev@@GLIBCXX_3.4
> /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld:
> CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: non-pic relocation against
> symbol _ZNSt8ios_base4InitD1Ev@@GLIBCXX_3.4
> /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld:
> CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: pc-relative relocation
> against dynamic symbol __cxa_atexit@@GLIBC_2.33
> /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld:
> final link failed: bad value
> collect2: error: ld returned 1 exit status

This link failure should be due to lacking of -fPIC

> make[2]: *** [CMakeFiles/geos.dir/build.make:5370: lib/libgeos.so.3.10.0dev]
> Error 1
> make[1]: *** [CMakeFiles/Makefile2:1173: CMakeFiles/geos.dir/all] Error 2
> 
> 
> 
> readelf -r CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o | grep
> __dso_handle
> 000059a4  0006aa23 R_OR1K_AHI16      00000000   __dso_handle + 0
> 000059a8  0006aa04 R_OR1K_LO_16_IN_I 00000000   __dso_handle + 0
> 
> 
>   readelf -r CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o | grep
> __cxa_atexit
> 000059bc  0006ac06 R_OR1K_INSN_REL_2 00000000   __cxa_atexit + 0
> 

Hi Stafford,

have you tried to reproduce it with Buildroot with this:
'''
# git clone git://git.busybox.net/buildroot
# wget https://git.busybox.net/buildroot-test/tree/utils/br-reproduce-build

- modify BASE_GIT=... with your buildroot path in br-reproduce-build then:
# chmod a+x br-reproduce-build
# ./br-reproduce-build 3eb9f9d0f6d8274b2d19753c006bd83f7d536e3c
'''
?

Other commands are needed to avoid rebuilding everything again and again.

so after the ones above:
# cd 9084cd777aefe0fa8235514c33767d8640ad7a5b
# cd output
# make V=1 libgeos
This ^^^^ is to rebuilding even if it failed and passing V=1 evrything 
is verbose, so you can get exactly C/CXX/LDFLAGS.
You can also find the sources of binutils under 
output/build/host-binutilsXX.X/ so there you can modify and then rebuild 
binutils with:
# cd output
# make host-binutils
This ^^^ should rebuild modified sources and re-install the binaries 
under output/host/usr/bin that is were buildroot takes binutils binaries.

I give you the exact FLAGS passed by Buildroot anyway:
CXX_FLAGS =  -DNDEBUG -fPIC   -ffp-contract=off -std=c++11
LDFLAGS = -fPIC  -DNDEBUG

Hope this helps

Best regards
Comment 15 Stafford Horne 2021-03-23 01:19:26 UTC
(In reply to Stafford Horne from comment #13)
> /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../..
> /../../or1k-smh-linux-gnu/bin/ld:
> CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: non-pic relocation
> against symbol _ZNSt8ios_base4InitD1Ev@@GLIBCXX_3.4
> /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../..
> /../../or1k-smh-linux-gnu/bin/ld:
> CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: non-pic relocation
> against symbol _ZNSt8ios_base4InitD1Ev@@GLIBCXX_3.4
> /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../..
> /../../or1k-smh-linux-gnu/bin/ld:
> CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: pc-relative relocation
> against dynamic symbol __cxa_atexit@@GLIBC_2.33
> /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../..
> /../../or1k-smh-linux-gnu/bin/ld: final link failed: bad value
> collect2: error: ld returned 1 exit status
> make[2]: *** [CMakeFiles/geos.dir/build.make:5370: lib/libgeos.so.3.10.0dev]
> Error 1
> make[1]: *** [CMakeFiles/Makefile2:1173: CMakeFiles/geos.dir/all] Error 2
> 
> 
> 
> readelf -r CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o | grep
> __dso_handle
> 000059a4  0006aa23 R_OR1K_AHI16      00000000   __dso_handle + 0
> 000059a8  0006aa04 R_OR1K_LO_16_IN_I 00000000   __dso_handle + 0
> 
> 
>  readelf -r CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o | grep
> __cxa_atexit
> 000059bc  0006ac06 R_OR1K_INSN_REL_2 00000000   __cxa_atexit + 0

OK, these errors are bogus.  They looked strange to me, the issue here was that I changed CXX_FLAGS mid build and it caused the new files to be created without -fPIC, so the final link created all these crazy issues.

Rebuilding now with the correct CXX_FLAGS throughout and I see, everything builds fine.  What error are you seeing?  Am I using the right libgeos?

< shorne@lianli ~/work/gnu-toolchain/geos > git remote -v
origin  https://git.osgeo.org/gitea/geos/geos.git (fetch)
origin  https://git.osgeo.org/gitea/geos/geos.git (push)

< shorne@lianli ~/work/gnu-toolchain/build-geos > make 
[  0%] Built target ryu
[ 57%] Built target geos
[ 58%] Built target geos_c
[ 92%] Built target test_geos_unit
[ 93%] Built target tinyxml2
[ 93%] Built target test_xmltester
[ 94%] Built target test_simplewkttester
[ 95%] Built target test_big_sweep_line_speed
[ 95%] Built target perf_class_sizes
[ 95%] Built target perf_unary
[ 95%] Built target perf_intersection
[ 95%] Built target perf_geospreparedcontains
[ 96%] Built target perf_memleak_mp_prep
[ 97%] Built target perf_unaryunion_segments
[ 97%] Built target perf_voronoi
[ 98%] Built target perf_interiorpoint_area
[ 98%] Built target perf_iterated_buffer
[ 98%] Built target perf_rectangle_intersects
[ 99%] Built target geosop
[100%] Built target astyle
Comment 16 Stafford Horne 2021-03-23 01:22:37 UTC
(In reply to Giulio Benetti from comment #14)
> Il 23/03/2021 00:36, shorne at sourceware dot org ha scritto:
> > https://sourceware.org/bugzilla/show_bug.cgi?id=21464
> 
> Hi Stafford,
> 
> have you tried to reproduce it with Buildroot with this:
> '''
> # git clone git://git.busybox.net/buildroot
> # wget https://git.busybox.net/buildroot-test/tree/utils/br-reproduce-build
> 
> - modify BASE_GIT=... with your buildroot path in br-reproduce-build then:
> # chmod a+x br-reproduce-build
> # ./br-reproduce-build 3eb9f9d0f6d8274b2d19753c006bd83f7d536e3c
> '''
> ?
> 
> Other commands are needed to avoid rebuilding everything again and again.
> 
> so after the ones above:
> # cd 9084cd777aefe0fa8235514c33767d8640ad7a5b
> # cd output
> # make V=1 libgeos
> This ^^^^ is to rebuilding even if it failed and passing V=1 evrything 
> is verbose, so you can get exactly C/CXX/LDFLAGS.
> You can also find the sources of binutils under 
> output/build/host-binutilsXX.X/ so there you can modify and then rebuild 
> binutils with:
> # cd output
> # make host-binutils
> This ^^^ should rebuild modified sources and re-install the binaries 
> under output/host/usr/bin that is were buildroot takes binutils binaries.
> 
> I give you the exact FLAGS passed by Buildroot anyway:
> CXX_FLAGS =  -DNDEBUG -fPIC   -ffp-contract=off -std=c++11
> LDFLAGS = -fPIC  -DNDEBUG
> 
> Hope this helps
> 
> Best regards

Hello,

I tried to use the br-reproduce-build command before but it was not working.  Let me try again with you extra steps.

Thanks.
Comment 17 Giulio Benetti 2021-03-23 01:55:46 UTC
And other useful commands:
To rebuild libgeos only from scratch:
# make V=1 libgeos-dirclean libgeos
also if you want to reissue make again only:
# make V=1 libgeos-rebuild

 Both inside output folder
Comment 18 Stafford Horne 2021-03-25 05:45:11 UTC
I confirm, when building with libgeos as you described I also see the familiar R_OR1K_GOT16 truncation issue.

I did some investigation, some points

  - In an earlier comment I mentioned the runtime PLT overflow, this is not related to this R_OR1K_GOT16 relocation, sorry my mistake.  When creating the PLT in or1k_elf_finish_dynamic_symbol the plt_reloc address may have a 16-bit overflow in the l.ori instruction which is not checked. Similar but a different issue.  Thats a different bug that I should raise.

  - This issue is an overflow in the 16-bit immediate in the l.lwz load instruction generated for R_OR1K_GOT16 by GCC.  So the fix has to start with GCC.  I will need to have a bit further look on how to handle this.

For the record some of the errors Errors:

linux-uclibc/9.3.0/crtbeginS.o: in function `__do_global_dtors_aux':
crtstuff.c:(.text+0x118): relocation truncated to fit: R_OR1K_GOT16 against symbol `__cxa_finalize' defined in .text section in 
/home/shorne/work/openrisc/3eb9f9d0f6d8274b2d19753c006bd83f7d536e3c/output/host/or1k-buildroot-linux-uclibc/sysroot/lib/libc.so.
1
crtstuff.c:(.text+0x140): relocation truncated to fit: R_OR1K_GOT16 against symbol `__deregister_frame_info@@GLIBC_2.0' defined 
in .text section in /home/shorne/work/openrisc/3eb9f9d0f6d8274b2d19753c006bd83f7d536e3c/output/host/opt/ext-toolchain/bin/../lib
/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/lib/libgcc_s.so
/home/shorne/work/openrisc/3eb9f9d0f6d8274b2d19753c006bd83f7d536e3c/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-
linux-uclibc/9.3.0/crtbeginS.o: in function `frame_dummy':
crtstuff.c:(.text+0x1a0): relocation truncated to fit: R_OR1K_GOT16 against symbol `__register_frame_info@@GLIBC_2.0' defined in
 .text section in /home/shorne/work/openrisc/3eb9f9d0f6d8274b2d19753c006bd83f7d536e3c/output/host/opt/ext-toolchain/bin/../lib/g
cc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/lib/libgcc_s.so
CMakeFiles/geos.dir/src/algorithm/BoundaryNodeRule.cpp.o: in function `geos::algorithm::BoundaryNodeRule::~BoundaryNodeRule()':
BoundaryNodeRule.cpp:(.text._ZN4geos9algorithm16BoundaryNodeRuleD2Ev[_ZN4geos9algorithm16BoundaryNodeRuleD5Ev]+0x24): relocation
 truncated to fit: R_OR1K_GOT16 against symbol `vtable for geos::algorithm::BoundaryNodeRule' defined in .data.rel.ro._ZTVN4geos
9algorithm16BoundaryNodeRuleE[_ZTVN4geos9algorithm16BoundaryNodeRuleE] section in CMakeFiles/geos.dir/src/algorithm/BoundaryNode
Rule.cpp.o
CMakeFiles/geos.dir/src/algorithm/CGAlgorithmsDD.cpp.o: in function `geos::algorithm::CGAlgorithmsDD::orientationIndex(double, d
ouble, double, double, double, double)':
CGAlgorithmsDD.cpp:(.text+0x308): relocation truncated to fit: R_OR1K_GOT16 against symbol `geos::util::IllegalArgumentException
::~IllegalArgumentException()' defined in .text._ZN4geos4util24IllegalArgumentExceptionD2Ev[_ZN4geos4util24IllegalArgumentExcept
ionD5Ev] section in CMakeFiles/geos.dir/src/algorithm/CGAlgorithmsDD.cpp.o
CGAlgorithmsDD.cpp:(.text+0x310): relocation truncated to fit: R_OR1K_GOT16 against symbol `typeinfo for geos::util::IllegalArgu
mentException' defined in .data.rel.ro._ZTIN4geos4util24IllegalArgumentExceptionE[_ZTIN4geos4util24IllegalArgumentExceptionE] se
ction in CMakeFiles/geos.dir/src/algorithm/CGAlgorithmsDD.cpp.o
CMakeFiles/geos.dir/src/algorithm/CGAlgorithmsDD.cpp.o: in function `geos::algorithm::CGAlgorithmsDD::signOfDet2x2(double, doubl
e, double, double)':
CGAlgorithmsDD.cpp:(.text+0xa34): relocation truncated to fit: R_OR1K_GOT16 against symbol `geos::util::IllegalArgumentException
::~IllegalArgumentException()' defined in .text._ZN4geos4util24IllegalArgumentExceptionD2Ev[_ZN4geos4util24IllegalArgumentExcept
ionD5Ev] section in CMakeFiles/geos.dir/src/algorithm/CGAlgorithmsDD.cpp.o
CGAlgorithmsDD.cpp:(.text+0xa3c): relocation truncated to fit: R_OR1K_GOT16 against symbol `typeinfo for geos::util::IllegalArgu
mentException' defined in .data.rel.ro._ZTIN4geos4util24IllegalArgumentExceptionE[_ZTIN4geos4util24IllegalArgumentExceptionE] se
ction in CMakeFiles/geos.dir/src/algorithm/CGAlgorithmsDD.cpp.o
CMakeFiles/geos.dir/src/algorithm/CGAlgorithmsDD.cpp.o: in function `geos::util::GEOSException::GEOSException(std::__cxx11::basi
c_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, s
td::allocator<char> > const&)':
CGAlgorithmsDD.cpp:(.text._ZN4geos4util13GEOSExceptionC2ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES9_[_ZN4geos4util
13GEOSExceptionC5ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES9_]+0xc0): additional relocation overflows omitted from
 the output
collect2: error: ld returned 1 exit status
make[4]: *** [CMakeFiles/geos.dir/build.make:5369: lib/libgeos.so.3.9.0] Error 1
make[3]: *** [CMakeFiles/Makefile2:359: CMakeFiles/geos.dir/all] Error 2
make[2]: *** [Makefile:172: all] Error 2
make[1]: *** [package/pkg-generic.mk:250: /home/shorne/work/openrisc/3eb9f9d0f6d8274b2d19753c006bd83f7d536e3c/output/build/libge
os-3.9.0/.stamp_built] Error 2
make: *** [Makefile:23: _all] Error 2
Comment 19 Giulio Benetti 2021-03-25 14:17:20 UTC
Ah, so 2 different bugs.
When you have some patch to test I can do it.
Please tag me in some way on gcc bugzilla when you submit the bug.

Thank you!
Comment 20 Stafford Horne 2021-03-26 00:00:32 UTC
Sure, I will open an issue in GCC there for the R_OR1K_GOT16 truncation issue.  I had a look at other architectures they have the ability to pass an argument -mcmodel=large or -mxgot to generate code that will handle large binary sizes.

I will have to implement something that does something similar in GCC and then add code to handle the new relocations in the assembler and linker/bfd.
Comment 21 cvs-commit@gcc.gnu.org 2021-05-06 11:52:59 UTC
The or1k-large-fixes branch has been updated by Stafford Horne <shorne@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=0b3e14c90283c5d234884d0ebe8510bc3c9bc687

commit 0b3e14c90283c5d234884d0ebe8510bc3c9bc687
Author: Stafford Horne <shorne@gmail.com>
Date:   Thu May 6 20:51:24 2021 +0900

    or1k: Implement relocation R_OR1K_GOT_AHI16 for gotha()
    
    The gotha() relocation mnemonic will be outputted by OpenRISC GCC when
    using the -mcmodel=large option.  This relocation is used along with
    got() to generate 32-bit GOT offsets.  This increases the previous GOT
    offset limit from the previous 16-bit (64K) limit.
    
    This is needed on large binaries where the GOT grows larger than 64k.
    
    bfd/ChangeLog:
    
            PR 21464
            * bfd-in2.h: Add BFD_RELOC_OR1K_GOT_AHI16 relocation.
            * elf32-or1k.c (or1k_elf_howto_table, or1k_reloc_map): Likewise.
            (or1k_final_link_relocate, or1k_elf_relocate_section,
            or1k_elf_check_relocs): Likewise.
            * libbfd.h (bfd_reloc_code_real_names): Likewise.
            * reloc.c: Likewise.
    
    cpu/ChangeLog:
    
            PR 21464
            * or1k.opc (or1k_imm16_relocs, parse_reloc): Define parse logic
            for gotha() relocation.
    
    include/ChangeLog:
    
            PR 21464
            * elf/or1k.h (elf_or1k_reloc_type): Define R_OR1K_GOT_AHI16 number.
    
    opcodes/ChangeLog:
    
            PR 21464
            * or1k-asm.c: Regenerate.
    
    gas/ChangeLog:
    
            PR 21464
            * testsuite/gas/or1k/reloc-1.s: Add test for new relocation.
            * testsuite/gas/or1k/reloc-1.d: Add test result for new
            relocation.
    
    Cc: Giulio Benetti <giulio.benetti@benettiengineering.com>
    
    fixup reloc, add tests
Comment 22 cvs-commit@gcc.gnu.org 2021-05-06 11:53:04 UTC
The or1k-large-fixes branch has been updated by Stafford Horne <shorne@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=3c3de29b048bca6b4aa4235c647b9328e71801b6

commit 3c3de29b048bca6b4aa4235c647b9328e71801b6
Author: Stafford Horne <shorne@gmail.com>
Date:   Thu May 6 20:51:25 2021 +0900

    or1k: Avoid R_OR1K_GOT16 overflow failures in presence of R_OR1K_GOT_AHI16
    
    Now that we support R_OR1K_GOT_AHI16 we can relax the R_OR1K_GOT16
    overflow validation check if the section has R_OR1K_GOT_AHI16.
    
    We cannot simple disable R_OR1K_GOT16 overflow validation as there will
    still be binaries that will have only R_OR1K_GOT16.  The
    R_OR1K_GOT_AHI16 relocation will only be added by GCC when building with
    the option -mcmodel=large.
    
    This assumes that R_OR1K_GOT_AHI16 will come before R_OR1K_GOT16, which
    is the code pattern that will be emitted by GCC.
    
    bfd/ChangeLog:
    
            PR 21464
            * elf32-or1k.c (or1k_elf_relocate_section): Relax R_OR1K_GOT16
            overflow check if we have R_OR1K_GOT_AHI16 followed by
            R_OR1K_GOT16.
Comment 23 cvs-commit@gcc.gnu.org 2021-05-06 11:53:45 UTC
The master branch has been updated by Stafford Horne <shorne@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=0b3e14c90283c5d234884d0ebe8510bc3c9bc687

commit 0b3e14c90283c5d234884d0ebe8510bc3c9bc687
Author: Stafford Horne <shorne@gmail.com>
Date:   Thu May 6 20:51:24 2021 +0900

    or1k: Implement relocation R_OR1K_GOT_AHI16 for gotha()
    
    The gotha() relocation mnemonic will be outputted by OpenRISC GCC when
    using the -mcmodel=large option.  This relocation is used along with
    got() to generate 32-bit GOT offsets.  This increases the previous GOT
    offset limit from the previous 16-bit (64K) limit.
    
    This is needed on large binaries where the GOT grows larger than 64k.
    
    bfd/ChangeLog:
    
            PR 21464
            * bfd-in2.h: Add BFD_RELOC_OR1K_GOT_AHI16 relocation.
            * elf32-or1k.c (or1k_elf_howto_table, or1k_reloc_map): Likewise.
            (or1k_final_link_relocate, or1k_elf_relocate_section,
            or1k_elf_check_relocs): Likewise.
            * libbfd.h (bfd_reloc_code_real_names): Likewise.
            * reloc.c: Likewise.
    
    cpu/ChangeLog:
    
            PR 21464
            * or1k.opc (or1k_imm16_relocs, parse_reloc): Define parse logic
            for gotha() relocation.
    
    include/ChangeLog:
    
            PR 21464
            * elf/or1k.h (elf_or1k_reloc_type): Define R_OR1K_GOT_AHI16 number.
    
    opcodes/ChangeLog:
    
            PR 21464
            * or1k-asm.c: Regenerate.
    
    gas/ChangeLog:
    
            PR 21464
            * testsuite/gas/or1k/reloc-1.s: Add test for new relocation.
            * testsuite/gas/or1k/reloc-1.d: Add test result for new
            relocation.
    
    Cc: Giulio Benetti <giulio.benetti@benettiengineering.com>
    
    fixup reloc, add tests
Comment 24 cvs-commit@gcc.gnu.org 2021-05-06 11:53:50 UTC
The master branch has been updated by Stafford Horne <shorne@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=3c3de29b048bca6b4aa4235c647b9328e71801b6

commit 3c3de29b048bca6b4aa4235c647b9328e71801b6
Author: Stafford Horne <shorne@gmail.com>
Date:   Thu May 6 20:51:25 2021 +0900

    or1k: Avoid R_OR1K_GOT16 overflow failures in presence of R_OR1K_GOT_AHI16
    
    Now that we support R_OR1K_GOT_AHI16 we can relax the R_OR1K_GOT16
    overflow validation check if the section has R_OR1K_GOT_AHI16.
    
    We cannot simple disable R_OR1K_GOT16 overflow validation as there will
    still be binaries that will have only R_OR1K_GOT16.  The
    R_OR1K_GOT_AHI16 relocation will only be added by GCC when building with
    the option -mcmodel=large.
    
    This assumes that R_OR1K_GOT_AHI16 will come before R_OR1K_GOT16, which
    is the code pattern that will be emitted by GCC.
    
    bfd/ChangeLog:
    
            PR 21464
            * elf32-or1k.c (or1k_elf_relocate_section): Relax R_OR1K_GOT16
            overflow check if we have R_OR1K_GOT_AHI16 followed by
            R_OR1K_GOT16.
Comment 25 Stafford Horne 2021-05-06 20:24:50 UTC
The latest commit should fix this.