This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

build-many-glibcs.py bot now running


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 
<https://sourceware.org/ml/libc-testresults/2016-q4/msg00002.html>.  The 
ColdFire failure is <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68467>.  
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 
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78460> (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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]