From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 128752 invoked by alias); 2 Dec 2016 14:21:39 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 128708 invoked by uid 89); 2 Dec 2016 14:21:37 -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=Hx-languages-length:2568, postings X-HELO: relay1.mentorg.com Date: Fri, 02 Dec 2016 14:21:00 -0000 From: Joseph Myers To: Subject: build-many-glibcs.py bot now running Message-ID: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-ClientProxiedBy: svr-ies-mbx-02.mgc.mentorg.com (139.181.222.2) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-SW-Source: 2016-12/txt/msg00049.txt.bz2 I'm now running a bot using build-many-glibcs.py to build glibc and run the compilation parts of the testsuite. You can see the most recent results at . The ColdFire failure is . The MicroBlaze failures are missing EH support in GCC. hppa is elf/check-execstack and elf/check-textrel failing and ia64 is elf/check-execstack failing (until those are fixed, additional compilation tests failing or tests failing to compile will not show up as a regression from the bot, so I encourage architecture maintainers to sort out those failures). The bot sleeps 4 hours between cycles (of course some cycles may not do anything if glibc hasn't changed since the last cycle) and will rebuild the compilers when they are 1 week old (otherwise just rebuilding glibc). I intend to add such a bot using GCC and binutils mainline once (out-of-memory testing for SH) is fixed (I'm running these bots on shared build servers, so don't want to run one with known out-of-memory issues). Once GCC 7 branches I'll probably move the GCC 6 bot to test GCC 7 instead (so just test the most recent GCC release branch and mainline rather than testing old GCC versions, though build-many-glibcs.py can be used for any GCC version 4.9 or later). Of course such a bot is more likely to find compiler issues, and cases where glibc needs updating for e.g. new compiler warnings. build-many-glibcs.py is a rough glibc analogue of GCC's contrib/config-list.mk (whose results I think someone may monitor); however, that only does "make all-gcc", whereas build-many-glibcs.py compiles the glibc testsuite and runs those tests that run with run-built-tests=no. It would be possible (and not that hard) and I think useful to do something for GCC that also builds binutils and runtime libraries and (with a suitable dummy board file) runs the compilation parts of the GCC testsuites, but monitoring its results would be rather more work than I expect monitoring results of these glibc bots to be. It would also be useful to add scripts for mailing results of the glibc testsuite (with summaries of the test environment / configuration) to libc-testresults so people can make their existing bots (or manual testsuite runs) do so; we want routine postings of results for the full testsuite including execution tests, not just these compilation results. -- Joseph S. Myers joseph@codesourcery.com