Created attachment 664246 [details]
I believe this is triggered by lto, because unless my memory fools me I already have built spidermonkey-78.2.0 with clang just to see if it works, which it does.
anyway, here's the most important output:
checking what kind of list files are supported by the linker... configure: error: Couldn't find one that works
DEBUG: <truncated - see config.log for full output>
DEBUG: configure:6445: checking for tm_zone tm_gmtoff in struct tm
DEBUG: configure:6457: /usr/lib/llvm/9/bin/clang++ -std=gnu++17 -c -O2 -pipe -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=hard -mfpu=neon -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno -pthread -pipe -Qunused-arguments conftest.C 1>&5
DEBUG: configure:6496: checking what kind of list files are supported by the linker
DEBUG: configure:6501: /usr/lib/llvm/9/bin/clang -std=gnu99 -o conftest.o -c -flto=thin -O2 -pipe -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=hard -mfpu=neon -ffunction-sections -fdata-sections -fno-math-errno -pthread -pipe -Qunused-arguments conftest.c 1>&5
DEBUG: configure:6508: /usr/lib/llvm/9/bin/clang -std=gnu99 -o conftest -flto=thin -Wl,-plugin-opt=-import-instr-limit=10 -lpthread -Wl,-O1 -Wl,--as-needed -Wl,-z,noexecstack -Wl,-z,text -Wl,-z,relro -Wl,-z,nocopyreloc -Wl,-Bsymbolic-functions conftest.list -lm -ldl 1>&5
DEBUG: /usr/lib/gcc/armv7a-unknown-linux-gnueabihf/9.3.0/../../../../armv7a-unknown-linux-gnueabihf/bin/ld: BFD (Gentoo 2.34 p6) 2.34.0 internal error, aborting at /var/tmp/portage/sys-devel/binutils-2.34-r2/work/binutils-2.34/bfd/elfcode.h:224 in bfd_elf32_swap_symbol_out
DEBUG: /usr/lib/gcc/armv7a-unknown-linux-gnueabihf/9.3.0/../../../../armv7a-unknown-linux-gnueabihf/bin/ld: Please report this bug.
Created attachment 664249 [details]
output from emerge --info
I've never triggered such an issue, is this an issue with binutils or with gcc?
There's a reason why firefox ebuild is forcing specific linker when you use LTO but spidermonkey does not expose USE=clang so you are on your own with this.
kind of, on amd64 with CC=clang it runs into linking error at the end of the build because it needs --enable-linker=lld to link the lto segments from clang.
here however, there's another problem and I'm uncertain where to look
ccing toolchain, you have any idea what happens here?
The ld input files are probably invalid. Perhaps clang-specific LTO sections can't be handled by binutils' ld.bfd. LTO format is compiler-specific.
Error message perhaps could be slightly better on binutils side. To say something with better certainty I'll need ld input files.
I still have the tmpdir and can upload them here, in which part are the ld files?
(In reply to tt_1 from comment #6)
> I still have the tmpdir and can upload them here, in which part are the ld
I don't think ./configure leaves temporary files around. config.log will show you exact linker command and .c source file that was used to produce it. From there you can add -Wl,--verbose option to see full ld input.
A toy example is 'LANG=C gcc-11.0.0 -Wl,--verbose a.c -o a |& fgrep succeeded'
so, after some digging:
the files used during the tests are in work/build, where conftest is executed by the linker. conftest is some sort of asci file which contains only one line: conftest.o
this file consists of llvm ir bitcode and I believe this is the reason why the bfd.ld linker flakes.
and also the reason propably why one has to use lld with clang, which passes the test.
I think this can be seen as fixed with new clang use flag, it sets up lld as a linker automatically and avoids these problems.