From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from angie.orcam.me.uk (angie.orcam.me.uk [IPv6:2001:4190:8020::34]) by sourceware.org (Postfix) with ESMTP id 482D33858D32 for ; Sat, 3 Jun 2023 20:32:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 482D33858D32 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=orcam.me.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=orcam.me.uk Received: by angie.orcam.me.uk (Postfix, from userid 500) id 9D0FD92009C; Sat, 3 Jun 2023 22:32:57 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id 8F05892009B; Sat, 3 Jun 2023 21:32:57 +0100 (BST) Date: Sat, 3 Jun 2023 21:32:57 +0100 (BST) From: "Maciej W. Rozycki" To: Thomas Schwinge cc: gcc-patches@gcc.gnu.org, Chung-Lin Tang , Rainer Orth , Mike Stump , Iain Sandoe , Julian Brown Subject: Re: Consider '--with-build-sysroot=[...]' for target libraries' build-tree testing (instead of build-time 'CC' etc.) [PR109951] In-Reply-To: <875y868a4b.fsf@euler.schwinge.homeip.net> Message-ID: References: <6594B30D-743B-4B4C-81CE-11DD3EE87C8C@comcast.net> <20200103113421.51b55ff5@squid.athome> <875y868a4b.fsf@euler.schwinge.homeip.net> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-3494.8 required=5.0 tests=BAYES_00,GIT_PATCH_0,KAM_DMARC_STATUS,KAM_INFOUSMEBIZ,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Thomas, > Will you, Maciej, please test that this doesn't break your setting? Umm, this was implemented for my Western Digital development environment, which I don't have access to anymore. I'll see what I can do, but it may be neither easy nor quick. It's been long ago and I don't have a setup with multilibs enabled anymore. And neither I remember the thorough problem analysis I went through that has led me to the conclusions. I've come across my note, in a reply to Chung-Lin's concerns, about using libgomp.exp as a standalone test driver. Has this been verified somehow with your proposed change? Also I've skimmed over your change and this has caught my eye: > diff --git a/libgomp/configure.ac b/libgomp/configure.ac > index 1aad83a79da..49f7fb0dc82 100644 > --- a/libgomp/configure.ac > +++ b/libgomp/configure.ac > @@ -151,22 +151,11 @@ AC_SUBST(enable_static) > > AM_MAINTAINER_MODE > > -# We optionally test libgomp C++ support, and for that want to use the proper > -# C++ driver, 'g++' (or 'xg++' for build-tree testing). Given that build of > -# target libstdc++-v3 depends on target libgomp (see '../Makefile.def'), we > -# cannot make build of target libgomp depend on target libstdc++-v3: circular > -# dependency. We thus cannot instantiate 'AC_PROG_CXX' here: we'd get > -# '-funconfigured-libstdc++-v3' (see '../configure.ac'). Therefore, just > -# capture 'CXX', and we'll fix this up at 'make check' time (see > -# 'testsuite/lib/libgomp.exp:libgomp_init'). > -AC_SUBST(CXX) > - > # Create a spec file, so that compile/link tests don't fail > test -f libgfortran.spec || touch libgfortran.spec > FCFLAGS="$FCFLAGS -L." > > -# We need 'gfortran' to compile parts of the library, and test libgomp Fortran > -# support. > +# We need gfortran to compile parts of the library > # We can't use AC_PROG_FC because it expects a fully working gfortran. -- missing full stop here, and I suggest to just make all this comment one paragraph (I can't imagine why it's not already, as the second sentence is clearly a continuation of the first one). I think a proper change description would be good too, as otherwise one may wonder why you have removed all the stuff above, and what this change is about anyway. Maciej