Re: [golang-dev] [PATCH] libgo/test: Add flags to find libgcc_s in build-tree testing

[Ian Lance Taylor <iant at golang dot org>]

[ moving from golang-dev to gofrontend-dev ]

On Mon, Nov 11, 2019 at 7:48 AM Maciej W. Rozycki <macro@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