We build devices that run Linux. We make our Linux environment from scratch, so we have an in-house routine of building binutils, gcc, glibc, busybox, and so on. It's standard stuff for those used to the joys of getting Linux built from scatch.
Summary: it's embarrassingly hard to build Linux from scratch. Everything needs a bit of gentle bodging to work. If you change one component of the Linux build chain, it's odds-on that you'll have to tinker with many others.
That's just life. Programming was never supposed to be easy, was it? But you don't want people to make the job any harder than it has to be.
So helpfully, in these enlightened times, the glibc release dudes now no longer supply tarballs of their source releases. And they don't really tell you that they don't either.
Here are the details...
Everything old is new again
The glibc homepage is here: http://www.gnu.org/software/libc
- The "Current status" section says that the latest version is 2.8
- The "Availability" section says that releases are available from the GNU FTP site (http://ftp.gnu.org/gnu/glibc/)
- The latest version available there is 2.7
- There are no other hints or bits of documentation about this
So what's any geek to do? I hit Google. And here's what I discovered:
Finding the truth
http://sourceware.org/ml/libc-alpha/2008-05/msg00074.html shows a mailing list post from the glibc maintainer which states that:
Tarballs are a completely outdated concept.And he refused to package glibc releases any more. Go get it from CVS yourself. Crumbs!
Helpfully, he's not only not packaging releases, he's also not telling people how to get them easily. And he's not making it clear that the FTP site is now NOT the source of the latest releases.
There is some well reasoned comment to this (including http://sourceware.org/ml/libc-alpha/2008-05/msg00076.html) highlighting the advantages of packaged source releases. Still, that's not my choice, and I can't help it.
So how do you get it?
The glibc resources page (http://www.gnu.org/software/libc/resources.html) describes the location of the project's CVS repository, and how to get sources from it via annonymous pserver access. However, there's no mention of the release tag you need to get a release.
So it's up to you, luck, and the raw power of CVS. This was a culture shock for me; it's been years since I last used CVS! And my finger memory won't even allow me to type cvs. Every time I tried typing it, it came out 'svn')
Helpfully you can't even "cvs ls" the repository as the server does not support "ls". Good start.
A bit of digging in the glibc CVSweb interface helped me to discover the tag was called glibc-2_8 and that the two modules I needed to check out were called "libc" and "ports"
Since our build system requires the traditional glibc and glibs-ports
tarballs as input to the build process, I needed to recreate some tarballs, even if they are not official release sets.
The script below is how to do this, for those in a similar predicament.
Later I found http://sourceware.org/glibc/ which is another (unofficial) glibc homepage that has slightly more info on it. However, it still doesn't tell you the release tag for the latest source release. Sigh.
Whinge, whinge, whinge
So what? I can hardly complain can I? I can't demand a refund for this shocking lack of unpaid support for the free software I'm using without cost? So I'll just have to have a bloggy moan about it instead.
cvs -z 9 -d :pserver:email@example.com:/cvs/glibc login
cvs -z 9 -d :pserver:firstname.lastname@example.org:/cvs/glibc export -r $RELEASE_TAG libc
cvs -z 9 -d :pserver:email@example.com:/cvs/glibc export -r $RELEASE_TAG ports
mv ports/ glibc-ports-$VERSION
mv libc/ glibc-$VERSION
tar cfj glibc-ports-$VERSION.tar.bz2 glibc-ports-$VERSION
tar cfj glibc-$VERSION.tar.bz2 glibc-$VERSION