From patchwork Thu Nov 17 17:47:14 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Joseph Myers X-Patchwork-Id: 17549 Received: (qmail 89532 invoked by alias); 17 Nov 2016 17:47:35 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 89520 invoked by uid 89); 17 Nov 2016 17:47:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_NONE, SPF_PASS, URIBL_RED autolearn=ham version=3.3.2 spammy=wish X-HELO: relay1.mentorg.com Date: Thu, 17 Nov 2016 17:47:14 +0000 From: Joseph Myers To: Zack Weinberg CC: Subject: Re: Add script to build many glibc configurations In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 X-ClientProxiedBy: svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) On Thu, 17 Nov 2016, Zack Weinberg wrote: > On 11/17/2016 11:52 AM, Zack Weinberg wrote: > > On 11/09/2016 11:27 AM, Joseph Myers wrote: > >> This patch adds a Python (3.5 or later) script to build many different > >> configurations of glibc, including building the required cross > >> compilers first. It's not intended to change any patch testing > >> requirements, although some people may wish to use it for high-risk > >> patches such as adding warning options ... > > > > Since this does its own glibc checkout, it's not clear to me how one > > should use it to test a patch(set). I presume that whatever one does, > > it only affects the "glibcs" step, but what actually do you do? Do you > > manually update /some/where/src/glibc to contain the code you want > > tested and then run "glibcs", or do you somehow tell > > build-many-glibcs.py the name of a branch you want tested, or what? > > I went ahead with the setup steps, and they failed during the compilers > phase. It seems that it's not picking up the host libraries I just > built. Now what? I've committed this patch to fix this. (The systems I tested on had suitable versions of these libraries installed where host GCC could find them, so I didn't notice that the newly built libraries weren't being used.) Actually use newly built host libraries in build-many-glibcs.py. This patch adds the missing GCC configure options required to make use of the newly built host libraries in build-many-glibcs.py. 2016-11-17 Joseph Myers * scripts/build-many-glibcs.py (Config.build_gcc): Configure with newly built gmp, mpfr and mpc. diff --git a/scripts/build-many-glibcs.py b/scripts/build-many-glibcs.py index be561c3..b0e0f5e 100755 --- a/scripts/build-many-glibcs.py +++ b/scripts/build-many-glibcs.py @@ -813,6 +813,10 @@ class Config(object): # relevance with glibc's own stack checking support. cfg_opts = list(self.gcc_cfg) cfg_opts += ['--disable-libsanitizer', '--disable-libssp'] + host_libs = self.ctx.host_libraries_installdir + cfg_opts += ['--with-gmp=%s' % host_libs, + '--with-mpfr=%s' % host_libs, + '--with-mpc=%s' % host_libs] if bootstrap: tool_build = 'gcc-first' # Building a static-only, C-only compiler that is