From patchwork Fri Sep 24 10:34:34 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Burgess X-Patchwork-Id: 1532195 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=embecosm.com header.i=@embecosm.com header.a=rsa-sha256 header.s=google header.b=AmI2rt9V; dkim-atps=neutral Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=8.43.85.97; helo=sourceware.org; envelope-from=gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 4HG7hX2JZ9z9sxS for ; Fri, 24 Sep 2021 20:35:04 +1000 (AEST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 27DA13858022 for ; Fri, 24 Sep 2021 10:35:01 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) by sourceware.org (Postfix) with ESMTPS id 564083858402 for ; Fri, 24 Sep 2021 10:34:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 564083858402 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=embecosm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=embecosm.com Received: by mail-wr1-x42e.google.com with SMTP id u18so26028309wrg.5 for ; Fri, 24 Sep 2021 03:34:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=gelfElu81M1YvSfglzvYqwfN6u4IXc8end4dYk51VUM=; b=AmI2rt9V+kGouwLYZYiT+1Q6TbKDwyXKtWXjSUyR1CqLdNK0a86WBLIAfEoCKLfnyH p5xmbLisJnB9oizbHZlT0VUBVT1kAHjXxUDIkbZ3Lil8AxEK+fk/aRecgNYfk52G0lF4 muUEEl7jSTUYWGb6c36lwUOYZ4uw8RvcInkUDl3tOHoNCY8/n6PilYfySxWp+pqF/Zgo MpeOf+5UxWxQPxGy67qumxuKK6iWHrX+FzxoRCRlbWeqVb7b+oM3B6JsFoLegnIfQqJE 8qzZzs8qiyUD8Uec++liUQ88ytZm6DfkwQoSic6pxOyvF+PevUz8yM2m88vQK/fR4DJy 6x1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=gelfElu81M1YvSfglzvYqwfN6u4IXc8end4dYk51VUM=; b=2tXZGCAfg+qhZOIet2LAxA1rgPtvADFmPAXLjKMwryXpcFz7LdhACEONrW67vcopRk XOQS2yv8FS2Ch4SaAMiwOwBKvXr4fUXVBqs8DWgBmC3VIjrjpQGgxG73Ws+QHapiUMZs TrGPc9kR/jEGMR9WkLyA355Co1IINpbuoNarMsuTbTM6oKeEQXzWvqwWyK2B7sKS2Fid LqAAcs4ltJl3rYsDMvioVf4BusVSnmpShN0sqMbY95wOciY5Y2l0UNX06CPe0A/QW2Yz xcFAiXzjeNculwHCqSWzXbZVoSkm1Fl43+qOOTn8Urz+6JZaPZrwYq8O2Pvb/eA2W+Wp iPwA== X-Gm-Message-State: AOAM533GxBQ+4uPsiufiheSPMjFl6uqCzioLEpyGZEX27QsqCNXVl42O qieTOkllJiaItzv1Euou34GDZg== X-Google-Smtp-Source: ABdhPJzAbjV0YYuJS0PUi8uPp+Qj+M1PMj4iy3N4fd9EUw2WBVFrpf7JVeeoJoGnzi8yrtZXvVZGtQ== X-Received: by 2002:a05:6000:186a:: with SMTP id d10mr10762554wri.113.1632479676199; Fri, 24 Sep 2021 03:34:36 -0700 (PDT) Received: from localhost (host86-169-137-11.range86-169.btcentralplus.com. [86.169.137.11]) by smtp.gmail.com with ESMTPSA id y64sm8689826wmc.38.2021.09.24.03.34.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Sep 2021 03:34:35 -0700 (PDT) Date: Fri, 24 Sep 2021 11:34:34 +0100 From: Andrew Burgess To: Thomas Schwinge Subject: [PATCHv2] top-level configure: setup target_configdirs based on repository Message-ID: <20210924103434.GB2435280@embecosm.com> References: <20210922153042.3491108-1-andrew.burgess@embecosm.com> <87tuibskri.fsf@euler.schwinge.homeip.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <87tuibskri.fsf@euler.schwinge.homeip.net> X-Operating-System: Linux/5.8.18-100.fc31.x86_64 (x86_64) X-Uptime: 11:24:43 up 5 days, 1:33, X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] X-Spam-Status: No, score=-10.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham 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: , Cc: gcc-patches@gcc.gnu.org Errors-To: gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org Sender: "Gcc-patches" * Thomas Schwinge [2021-09-23 11:29:05 +0200]: > Hi! > > I only had a curious look here; hope that's still useful. > > On 2021-09-22T16:30:42+0100, Andrew Burgess wrote: > > 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 != 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="target-rda" > > ## We assign ${configdirs} this way to remove all embedded newlines. This > > ## 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=`echo ${host_libs} ${host_tools}` > > -target_configdirs=`echo ${target_libraries} ${target_tools}` > > +if test -d ${srcdir}/gcc; then > > + target_configdirs=`echo ${target_libraries} ${target_tools}` > > +else > > + target_configdirs="" > > +fi > > build_configdirs=`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? Good point, I'd failed to spot these. > > 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), Great idea, this is what I've done in the revised patch below. > I wonder if it'd make sense to turn all > existing 'target_libraries=[...]' and 'target_tools=[...]' assignments > and later amendments into '[...]_gcc=[...]' 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/'? I wasn't really sure about this idea. It feels neater to have one list of things we want to build, and just make sure that the list is correct by the time we get to the end of the configure script. Also, making that change would be much larger, and more disruptive... I'd prefer to keep things smaller if possible. The V2 patch below: - Moves the check for gcc/ to much later in the configure script, after we've finished building target_configdirs, - Makes use of skipdirs to avoid building anything from target_configdirs if we're not also building gcc. All feedback welcome, Thanks, Andrew --- commit 84c8b7f1605c8f2840d3c857a4d86abc7dde0668 Author: Andrew Burgess Date: Wed Sep 22 15:15:41 2021 +0100 top-level configure: setup target_configdirs based on repository 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. 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. In the configure script we build three lists of things we want to build, $configdirs, $build_configdirs, and $target_configdirs, we also build two lists of things we don't want to build, $skipdirs and $noconfigdirs. We then remove anything that is in the lists of things not to build, from the list of things that should be built. My proposal is to add everything in target_configdirs into skipdirs, if the source tree doesn't contain a gcc/ sub-directory. The result is that for binutils-gdb no target tools or libraries will be built, while for the gcc repository, nothing should change. If a user builds a unified source tree, then the target tools and libraries should still be built as the gcc/ directory will be present. 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'. ChangeLog: * configure: Regenerate. * configure.ac (skipdirs): Add the contents of target_configdirs if we are not building gcc. diff --git a/configure b/configure index 85ab9915402..785498efff5 100755 --- a/configure +++ b/configure @@ -8874,6 +8874,16 @@ case ,${enable_languages}, in ;; esac +# If gcc/ is not in the source tree then we'll not be building a +# target compiler, assume in that case we don't want to build any +# target libraries or tools. +# +# This was added primarily for the benefit for binutils-gdb who reuse +# this configure script, but don't always have target tools available. +if test ! -d ${srcdir}/gcc; then + skipdirs="${skipdirs} ${target_configdirs}" +fi + # Remove the entries in $skipdirs and $noconfigdirs from $configdirs, # $build_configdirs and $target_configdirs. # If we have the source for $noconfigdirs entries, add them to $notsupp. diff --git a/configure.ac b/configure.ac index 1df038b04f3..c523083c346 100644 --- a/configure.ac +++ b/configure.ac @@ -2272,6 +2272,16 @@ case ,${enable_languages}, in ;; esac +# If gcc/ is not in the source tree then we'll not be building a +# target compiler, assume in that case we don't want to build any +# target libraries or tools. +# +# This was added primarily for the benefit for binutils-gdb who reuse +# this configure script, but don't always have target tools available. +if test ! -d ${srcdir}/gcc; then + skipdirs="${skipdirs} ${target_configdirs}" +fi + # Remove the entries in $skipdirs and $noconfigdirs from $configdirs, # $build_configdirs and $target_configdirs. # If we have the source for $noconfigdirs entries, add them to $notsupp.