From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa3.mentor.iphmx.com (esa3.mentor.iphmx.com [68.232.137.180]) by sourceware.org (Postfix) with ESMTPS id 7290C3857C44 for ; Thu, 23 Sep 2021 09:29:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7290C3857C44 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com IronPort-SDR: M9c0mPDZ8FGX0oAa5oPAENqQ0XsbIfTf7HSUs2r8doy9Dav8nlKEuN5JHeQ2iFrzs1gua5+EsO SYcuWpX9ukgy0xWL6pUJKY0viVZovRjVuFBy1WVxf0Kn0udmk6X+FtX0ZRLEI1sjLCigN+t2Qm umaNObTHLPzMGqIACoOCQwxPbNTngFAHPsPFjd6PhxBzoxlomVAwGlSmC4TQ4U3FVzDBS88o2O OPcmvuxxTMjxMovI5LszQTbQSFzuTQCCJi6zPGDRZXGp/6AUQafI6Ct4WM6toap0aOqSVD91RN Cc8eFv3AFXI+OXZWbGqg0L5p X-IronPort-AV: E=Sophos;i="5.85,316,1624348800"; d="scan'208";a="66198824" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa3.mentor.iphmx.com with ESMTP; 23 Sep 2021 01:29:13 -0800 IronPort-SDR: U0sEHWOJpCBUtZsILzvmN2HUdi2lBG5fub9utFdgqzivDz9Ywyt5+d5ri4lUnC4QgVuUd3l78k LCYAcsM/t4I1k6j4XzgXP5lA6VjMUhSsWHgQJ8TKmuUsFVPO+3247AoJbKELWPXqSrUtmS0Pj8 RnBQKMLt7wOOi6IbOZfaYdz5PbJrXrRjTeCIp+xudiY7FxpFZaTxvXg+1WjW+3akg7krO2MzWO qD7QRbDbd+wKl3+JBObCaHWrbHIoIHPCHhSaHhKxrln8XpzqFZcduW5OVJPix7CsmJ+5Pj/YxS 54M= From: Thomas Schwinge To: Andrew Burgess CC: , Richard Biener Subject: Re: [PATCH] top-level configure: setup target_configdirs based on repository In-Reply-To: <20210922153042.3491108-1-andrew.burgess@embecosm.com> References: <20210922153042.3491108-1-andrew.burgess@embecosm.com> User-Agent: Notmuch/0.29.3+94~g74c3f1b (https://notmuchmail.org) Emacs/27.1 (x86_64-pc-linux-gnu) Date: Thu, 23 Sep 2021 11:29:05 +0200 Message-ID: <87tuibskri.fsf@euler.schwinge.homeip.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-09.mgc.mentorg.com (139.181.222.9) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Sep 2021 09:29:18 -0000 Hi! I only had a curious look here; hope that's still useful. On 2021-09-22T16:30:42+0100, Andrew Burgess w= rote: > The top-level configure script is shared between the gcc repository > and the binutils-gdb repository. > > The target_configdirs variable in the configure.ac script, defines > sub-directories that contain components that should be built for the > target using the target tools. > > Some components, e.g. zlib, are built as both host and target > libraries. > > This causes problems for binutils-gdb. If we run 'make all' in the > binutils-gdb repository we end up trying to build a target version of > the zlib library, which requires the target compiler be available. > Often the target compiler isn't immediately available, and so the > build fails. I did wonder: shouldn't normally these target libraries be masked out via 'noconfigdirs' (see 'Handle --disable- generically' section), via 'enable_[...]' being set to 'no'? But I think I now see the problem here: the 'enable_[...]' variables guard both the host and target library build! (... if I'm quickly understanding that correctly...) ... and you do need the host zlib, thus '$enable_zlib !=3D no'. > The problem with zlib impacted a previous attempt to synchronise the > top-level configure scripts from gcc to binutils-gdb, see this thread: > > https://sourceware.org/pipermail/binutils/2019-May/107094.html > > And I'm in the process of importing libbacktrace in to binutils-gdb, > which is also a host and target library, and triggers the same issues. > > I believe that for binutils-gdb, at least at the moment, there are no > target libraries that we need to build. > > My proposal then is to make the value of target_libraries change based > on which repository we are building in. Specifically, if the source > tree has a gcc/ directory then we should set the target_libraries > variable, otherwise this variable is left entry. > > I think that if someone tries to create a single unified tree (gcc + > binutils-gdb in a single source tree) and then build, this change will > not have a negative impact, the tree still has gcc/ so we'd expect the > target compiler to be built, which means building the target_libraries > should work just fine. > > However, if the source tree lacks gcc/ then we assume the target > compiler isn't built/available, and so target_libraries shouldn't be > built. > > There is already precedent within configure.ac for check on the > existence of gcc/ in the source tree, see the handling of > -enable-werror around line 3658. (I understand that one to just guard the 'cat $srcdir/gcc/DEV-PHASE', tough.) > I've tested a build of gcc on x86-64, and the same set of target > libraries still seem to get built. On binutils-gdb this change > resolves the issues with 'make all'. > > Any thoughts? > --- a/configure.ac > +++ b/configure.ac > @@ -180,9 +180,17 @@ target_tools=3D"target-rda" > ## We assign ${configdirs} this way to remove all embedded newlines. Th= is > ## is important because configure will choke if they ever get through. > ## ${configdirs} is directories we build using the host tools. > -## ${target_configdirs} is directories we build using the target tools. > +## > +## ${target_configdirs} is directories we build using the target > +## tools, these are only needed when working in the gcc tree. This > +## file is also reused in the binutils-gdb tree, where building any > +## target stuff doesn't make sense. > configdirs=3D`echo ${host_libs} ${host_tools}` > -target_configdirs=3D`echo ${target_libraries} ${target_tools}` > +if test -d ${srcdir}/gcc; then > + target_configdirs=3D`echo ${target_libraries} ${target_tools}` > +else > + target_configdirs=3D"" > +fi > build_configdirs=3D`echo ${build_libs} ${build_tools}` What I see is that after this, there are still occasions where inside 'case "${target}"', 'target_configdirs' gets amended, so those won't be caught by your approach? Instead of erasing 'target_configdirs' as you've posted, and understanding that we can't just instead add all the "offending" ones to 'noconfigdirs' for '! test -d "$srcdir"/gcc/' (because that would also disable them for host usage), I wonder if it'd make sense to turn all existing 'target_libraries=3D[...]' and 'target_tools=3D[...]' assignments and later amendments into '[...]_gcc=3D[...]' variants, with potentially further variants existing -- but probably not, because won't you always need the target GCC to be able to build target libraries ;-) -- and then, where we finally evalue '$target_libraries' and '$target_tools', only evaluate the '[...]_gcc' variants iff 'test -d "$srcdir"/gcc/'? (All that completely untested, of course...) Gr=C3=BC=C3=9Fe Thomas ----------------- Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstra=C3=9Fe 201= , 80634 M=C3=BCnchen; Gesellschaft mit beschr=C3=A4nkter Haftung; Gesch=C3= =A4ftsf=C3=BChrer: Thomas Heurung, Frank Th=C3=BCrauf; Sitz der Gesellschaf= t: M=C3=BCnchen; Registergericht M=C3=BCnchen, HRB 106955