From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8112 invoked by alias); 2 Dec 2019 23:40:00 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 8063 invoked by uid 89); 2 Dec 2019 23:40:00 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=harmless, TCL, assembled, H*RU:209.85.208.65 X-HELO: mail-ed1-f65.google.com Received: from mail-ed1-f65.google.com (HELO mail-ed1-f65.google.com) (209.85.208.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 02 Dec 2019 23:39:58 +0000 Received: by mail-ed1-f65.google.com with SMTP id j17so1351550edp.3 for ; Mon, 02 Dec 2019 15:39:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=golang-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HZJjZHtncQ/WyPoHNAD1g+JKuP/ZzVgO4AZRvAsTWbo=; b=O3UMo6t05CzA/8DVSPdu+l+7rLH8kuD3Eqappo4SxxOD3DHR9cijTN5CWtygK2QKfQ hnG8jjRBIJFwto0RN3+EXF0qHrj1GGt36ecaCUQomo0ovoC+O3FDb9IM92+ITOMJWIxe JT1tMc3zfi1XxdXI9w23o9C1pasTfge02LWZeC67ttnT6OXwyUxHH5VoNZUHrdKejmdY ON2sOArCqxoWRQiNo8ybREzgyps2fj299zcsB4CoygjTHrMwViOjAaeWpIDqqLuIPMwq d0i6wvYGQ8SGhCnHTYUJNyzj3kpZGvySvNrNf4RaTdzprB9O1ecJN2DH/H8bhiireV1o qtXw== MIME-Version: 1.0 References: In-Reply-To: From: Ian Lance Taylor Date: Mon, 02 Dec 2019 23:40:00 -0000 Message-ID: Subject: Re: [PATCH v2 2/2] testsuite: Fix run-time tracking down of `libgcc_s' To: "Maciej W. Rozycki" Cc: gcc-patches , Richard Sandiford Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2019-12/txt/msg00093.txt.bz2 On Fri, Nov 29, 2019 at 1:09 AM Maciej W. Rozycki wrote: > > 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. This patch is for better Go support but the patch is to generic code. The patch is fine with me but should ideally be reviewed by a testsuite maintainer. Ian