[ moving from golang-dev to gofrontend-dev ] On Mon, Nov 11, 2019 at 7:48 AM Maciej W. Rozycki <ma...@wdc.com> wrote: > > Add a setting for the dynamic loader to find the shared libgcc_s library > in build-tree testing, fixing a catastrophic libgo testsuite failure in > cross-compilation where the library cannot be found by the loader at run > time and consequently no test case executes, producing output (here with > the `x86_64-linux-gnu' host and the `riscv64-linux-gnu' target, with > RISC-V QEMU in the Linux user emulation mode as the target board) like: > > spawn qemu-riscv64 -E > LD_LIBRARY_PATH=.:.../riscv64-linux-gnu/lib64/lp64d/libgo/.libs ./a.exe > ./a.exe: error while loading shared libraries: libgcc_s.so.1: cannot open > shared object file: No such file or directory > FAIL: archive/tar > > Use the `ld_library_path' TCL variable to propagate the setting obtained > from where GCC finds the library at link time, making test output look > like: > > spawn qemu-riscv64 -E > LD_LIBRARY_PATH=.:..././gcc/lib64/lp64d:.../riscv64-linux-gnu/lib64/lp64d/libgo/.libs > ./a.exe > PASS > PASS: archive/tar > > No summary comparison, because the libgo testsuite does not provide one > in this configuration for some reason, however this change improves > overall results from 0 PASSes and 159 FAILs to 133 PASSes and 26 FAILs. > > gcc/testsuite/ > * lib/go.exp (go_link_flags): Add `ld_library_path' setting to > find shared `libgcc_s' library at run time in build-tree > testing.
Is there similar code for other languages, such as Fortran? I don't see why Go would be different here. > Regression-tested with `make check-go' with the `x86_64-linux-gnu' native > system as well as the `x86_64-linux-gnu' host and the `riscv64-linux-gnu' > target, with RISC-V QEMU in the Linux user emulation mode as the target > board. > > NB as a heads-up numerous tests fail quietly (i.e. with no FAIL report > and no name of the test case given either) to link due to unsatisfied > symbol references, such as: > > .../bin/riscv64-linux-gnu-ld: _gotest_.o: in function > `cmd..z2fgo..z2finternal..z2fcache.Cache.get': > .../riscv64-linux-gnu/libgo/gotest24771/test/cache.go:182: undefined > reference to `cmd..z2fgo..z2finternal..z2frenameio.ReadFile' > > which I take is due to a reference to `libgotool.a' -- which is where the > required symbols are defined -- missing from the linker invocation. I > don't know what's supposed to supply the library to the linker or whether > this indeed the actual cause; I find the way libgo tests have been wired > unusual and consequently hard to follow, so maybe someone more familiar > with this stuff will be able to tell what is going on here. I'll be happy > to push any patches through testing. (That is, of course, a libgo test failure, and as such is not affected by your patch to go.exp.) In normal usage, that test is linked against libgotool.a because of the variable extra_check_libs_cmd_go_internal_cache in libgo/Makefile.am. That variable is added to GOLIBS in the CHECK variable in libgo/Makefile.am. Maybe the fix is for libgo/testsuite/lib/libgo.exp to use GOLIBS. Ian
