This is the mail archive of the
mailing list for the glibc project.
buildbot for glibc
- From: Roland McGrath <roland at hack dot frob dot com>
- To: "GNU C. Library" <libc-alpha at sourceware dot org>
- Cc: Kostya Serebryany <kcc at google dot com>, Sergey Matveev <earthdok at google dot com>
- Date: Wed, 11 Feb 2015 17:06:20 -0800 (PST)
- Subject: buildbot for glibc
- Authentication-results: sourceware.org; auth=none
Google is now hosting a new buildbot setup for glibc as a service to the
community. Things are extremely primitive at the moment, but we hope to
improve and expand the setup in the future (with your help!).
The hosts are virtual machines provided by Google Compute Engine. The
machine resources and setup help are being donated by Google's Dynamic
Tools group (maintainers of AddressSanitizer et al). Special thanks to
Sergey Matveev for doing the initial installation and for ongoing help with
the setup and administration.
You can see the build status at:
That name (on my personal server) is a simple redirect to the actual page,
which does not yet have a pretty URL. We'll need some help figuring out
exactly how best to set things up to yield a more pleasant browsing
You can currently get the buildbot configuration and build scripts with:
svn co https://address-sanitizer.googlecode.com/svn/trunk/glibc_buildbot
We want eventually to find a more appropriate place for that stuff to live,
where the glibc community can collaborate directly on maintaining the setup.
For now, there are two "bots", both actually running on the same one
virtual machine (called a "slave" in Buildbot lingo). One does the basic
x86_64-linux-gnu build, and one the basic i686-linux-gnu build.
Fresh builds are kicked off every time there is a new commit to master.
It polls every few minutes to notice.
The slave OS installation is based on Debian wheezy, which has only GCC
4.7. The i686 build always fails in 'make check' because I haven't figured
out what packages to install so that 'g++ -m32' will find -lstdc++.
(Actually, I just installed another one and it might work next cycle.)
The x86_64 build has a few test failures (but all the tests do build),
which I have not looked into yet. The build logs do not get much
information about how they fail, just the summary emitted at the end. I
can log into the slave and poke around, but I don't think I'll be able to
offer that access to people outside Google. Perhaps someone should whip
up a script that examines tests.sum and prints out the .test-result and
.out files for each FAIL--though that is by no means necessarily enough
information to understand the failure mode.
As with all infrastructure for the project, there is no big supply of paid
hacker time to work on this. It's intended to grow to be of great use to
us developers and maintainers, but the only way that will happen is if more
folks in the community pitch in to improve and maintain it.