testsuite: Fix run-time tracking down of `libgcc_s'
authorMaciej W. Rozycki <macro@wdc.com>
Sun, 22 Dec 2019 00:28:20 +0000 (00:28 +0000)
committerMaciej W. Rozycki <macro@gcc.gnu.org>
Sun, 22 Dec 2019 00:28:20 +0000 (00:28 +0000)
commitd42b84f427e404e6deca78a4cc76c40ab506d737
tree5083b9c0ff8d728b02df77c3ce51e6ef4ecee33b
parentbcfcf777bd1449f3bdca10766c5044bae75f1b8b
testsuite: Fix run-time tracking down of `libgcc_s'

Fix a catastrophic libgo testsuite failure in cross-compilation where
the shared `libgcc_s' library cannot be found by the loader at run time
in build-tree testing and consequently all test cases fail the execution
stage, giving 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

To do so rework `gcc-set-multilib-library-path' so as not to rely on the
`rootme' TCL variable to have been preset in testsuite invocation, which
only works for the GCC test suites and not for library test suites, and
also use `remote_exec host' rather than `exec' to invoke the compiler in
determination of `libgcc_s' locations, so that the solution works in
remote testing as well while also avoiding the hardcoded limit of the
executable's path length imposed by `exec'.

This is based on an observation that the multilib root directory can be
determined by stripping out the multilib directory in effect as printed
with the `-print-multi-directory' option from the path produced by the
`-print-file-name=' option.  And then individual full multilib paths can
be assembled for the other multilibs by appending their respective
multilib directories to the multilib root directory.

Unlike with the old solution the full multilib paths are not checked for
the presence of the shared `libgcc_s' library there, but that is
supposed to be harmless.  Also the full multilib path for the multilib
used with the compiler used for testing will now come first, which
should reduce run-time processing in the usual case.

With this change in place test output instead looks like:

spawn qemu-riscv64 -E LD_LIBRARY_PATH=.:.../riscv64-linux-gnu/lib64/lp64d/libgo/.libs:..././gcc/lib64/lp64d:..././gcc/.:..././gcc/lib32/ilp32:..././gcc/lib32/ilp32d:..././gcc/lib64/lp64 ./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/gcc-defs.exp (gcc-set-multilib-library-path): Use
`-print-file-name=' to determine the multilib root directory.
Use `remote_exec host' rather than `exec' to invoke the
compiler.

From-SVN: r279706
gcc/testsuite/ChangeLog
gcc/testsuite/lib/gcc-defs.exp