Great. Something else for me to have a techie moan about. It's not as if I have any actual work to do, is it?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.
Sigh.
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.
RELEASE_TAG=glibc-2_8
VERSION=2.8
cvs -z 9 -d :pserver:anoncvs@sources.redhat.com:/cvs/glibc login
cvs -z 9 -d :pserver:anoncvs@sources.redhat.com:/cvs/glibc export -r $RELEASE_TAG libc
cvs -z 9 -d :pserver:anoncvs@sources.redhat.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
42 comments:
I knew before I looked that email was going to be from Uli Drepper. He's got the coding chops, but he's, erm, abrasive at best. My way is so obviously the only write way to do it, the entire world should change to match me.
I particularly liked the "If I would have made a 2.8 tarballs then I shortly afterwards would have had to made 2.8.1 and perhaps more. "
I don't know about you, but I get software to that kind of thing for me ...
Yeah, Jez.
To me it's rather like being the manufacturer of the most popular baked beans brand in town.
You improve the recipe by adding a new secret ingredient. You spend ages developing the secret ingredient. You spend lots of money on a nationwide advertising campaign.
Then you don't put the new baked beans in the supermarkets. You leave the old baked beans there (which people presume is the new one and don't notice the difference).
You then leave instructions on how to make the new secret recipe elsewhere - not in the supermaket, nor on the tins of baked beans, but in a recipe book that you have to get from the manufacturer.
It allows the people who buy "value" baked beans to be smug :-)
RELEASE_TAG=glibc-2_8
VERSION=2.9
Err... you sure about that version string...?
Thanks, Brian! Point taken... Just a little more madness :-)
The problem is simple - the company in question has changed their strategy not long ago by tightening their control over key software.
However, I find it hilarious that RMS continually trolls about the freedom of the GNU project while at the same time projects like Glibc (but GCC too, to a lesser extent though) continually and purposely misbehave. Pretty every GNU project offers tarballs. That can't be that difficult, no?
There is no way to change this situation however. Why not? Because the developers in question do not care.
I can only encourage people to become as independent as possible from arrogant developers. These developers will continually make idiotic claims, but in essence the main problem is their arrogant, inflated ego and hate against "Average Joe Sixpack" while they introduce problems for others.
And - in the case of Glibc - this is done on purpose by ALL their developers.
Personally, I'd just use the Debian source packages & tweak them for my own purposes. Let the Debian maintainers deal with U.Drepper :)
can't you just run your scripts as a cron job every day, check for a new tag, make a tar ball of the new tagged release, upload to your ftp server. Stick a page up with a HOW TO and shove adsense all over it. Make a few bucks, help the community, etc.
Haha, I was reading this and thought "this sounds like Drepper", turns out I was right.
That guy is a problem. I'd rather have someone with lesser skills and less of a social problem.
I wonder how many of the commenters have actually ever had the need to build glibc?
Anyway, the suggestion to use the debian source package is a good one.
Some projects have a very real need to build their own Linux systems from scratch rather than rely on a third party distribution like Debian.
For embedded systems running specific processors, certain combinations of the toolchain (binutils/gcc/glbc) do not play well together and you have to get the sources by hand and configure/tweak/patch to make things work.
Sadly, this kind of task will never be easy, but it's not helped by idiotic packaging policies like glibc's.
Oh boy, I thought this was about some technical glibc issue. Turns out everybody is wining because the release isn't packaged like they want, which doesn't matter to 99.9% of the people... Just ridiculous nagging to nag.
FredV...
Yes, it's an observation that the 2.8 release isn't packaged in the same way as any other previous glibc release, or any other release of a contemporary piece of Unix software.
But that's not the actual complaint.
The complaint is that it's really, really, really hard to get glibc, because it is not documented at all how to get it.
Go to the website. Try to work it out.
Without some work on Google you cannot get the latest version of glibc, as far as I can see.
That's the complaint!
Who are the 99.9% of glibc users? Indirect glibc users are the people using Linux distros. True, they don't care about this one iota. But the direct users - the people building glibc themselves (distro maintainers, embedded engineers, and the like) really do care about this. A lot!
A nice in-between solution, I think, is to use Git instead of CVS. The gitweb interface makes it very easy to get tarballs of any tag/revision/commit. I've found a gitweb-enabled mirror of the official glibc Git repository here:
http://repo.or.cz/w/glibc.git
plouj - that's a very interesting interim bodge. (Let's not consider whether adding an additional layer of indirection could instead lead to other problems, due to bugs in gitweb or other user error!)
But it doesn't get away from the fact that the glibc project really ought to help people to get their latest version of glibc.
Even just a little teensie bit of help like saying where it is :-)
Oh quit your belly aching. The real problem is that these pseudo programmers get this idea in their head that they somehow get the whole programming thing and then go whining about silly little stuff(like tarballs for heavens sake).
The equivalent of 'cvs ls' is actually 'cvs co -c'.
The real solution is to fork it and let someone do a better job. Distros will leave Drepper behind without a second thought. He will whine and it will not matter.
dietlibc
uclibc
I'm just saying.
@tonetheman: forking glibc? you do not know what you're talking about. i'm sure porting opensolaris libc is feasible but the fact is that Ulrich Drepper might be harsh, yes, and might not package glibc, but he and the other glibc people are overall doing a fantastic job.
(There are some things I don't like, such as peppering warn_unused_result attributes all over the place. And yes, I did work with Uli since I contributed quite a few optimizations and bugfixes for the regex engine of glibc).
Wow, I think you raised some very valid points here.
www.online-privacy.cz.tc
Indeed. I don't think that it is in anyone's interests to fork glibc. There are many alternatives to glibc, but they don't quite provide what glibc provides. Glibc is a great project.
The real answer is for a volunteer packager to step forward to handle to release cycle and packaging of glibc releases, to take this burden from Drepper's hands. Then everyone would be happy.
In an ideal world, I'd step forward to provide the solution. However, I don't have the time to contribute this service (easy as is probably would be) right now, so rather than providing a solution in the true Open Source Way, I'm just moaning about the problem.
Users, eh?...
Classic...
Jez pointed out to me that glibc uses autotools.
If you go into the glibc tree, and type make dist you get all the tarballs packaged for free.
So the main packaging problem is typing a single command and copying files to the ftp server. It doesn't take long, does it?!
Shame they're outdated. Perhaps I'm just an old fashioned kinda guy.
I build a Linux From Scratch (LFS) back in...I want to say 2001 or 2002. It was a huge learning experience and I used that build (and updated it by hand) for two semesters.
I switched to Fedora afterward (and now I've been on Gentoo for several years), but building an LFS help me really appreciate the build process and package management.
I wonder if LFS is still around and if it has been updated to tell users how to pull glibc from CVS.
And I agree, saying tarballs are outdated and then still using something like CVS as opposed to Git or SVN... how hard is it to automate the process of creating that tarball? You can attach scripts to CVS checkins and tagging.
I guess it's only something distro package managers and embedded system developers really care about, but it's good to know.
I'm pretty sure that glibc-2_8 is a branch, not a tag. That's why he does not package. The tip of the stable branch is always more up-to-date than any tarball.
When was the last time you met a systems developer whining about using CVS instead of FTP? The stuff you describe is non-issue, seriously. Glibc is a work of masters, stop whining.
Heheheh!
Last time I read my blog, I guess.
Glibc is great. But nothing's perfect. Not even my code :-O
I understand why some people prefer FreeBSD....
Tar is an outdated concept? And CVS is not?!
If you're grabbing from CVS anyway, you could pull the latest snapshot tarball from ftp://sources.redhat.com/pub/glibc/snapshots/
Particularly ftp://sources.redhat.com/pub/glibc/snapshots/glibc-2.8-latest.tar.bz2 and ftp://sources.redhat.com/pub/glibc/snapshots/glibc-2.8-ports-latest.tar.bz2
I apologize for the lack of updates to the website. We are always looking for more volunteers to help with the project.
The availability information has been updated on both the sourcware and gnu.org sites.
http://www.gnu.org/software/libc/#Availability
http://sourceware.org/glibc/
In the future please contact the libc-help mailing list if you feel any of the websites are out-of-date.
Cheers,
Carlos O'Donell
carlos@systemhalted.org
AMAZING FOTO ! - http://visualunique.com/topolm.html
Why run a C library designed for desktops and servers when there are better choices specifically designed for embedded use?
I don't think I was the only one who read the blog and thought "oh god, that's gotta be Ulrich Drepper again!" :-/
Then click on the link and sure enough, it's confirmed.
That guy ranks pretty high on the a**holery scale, somewhere in the region of Bill O'Reilly or so.
It is not 'embarrassingly hard', it is justifiably hard. Bootstrapping a toolchain is a complicated process, made more complicated if you need to bridge ABIs or bootstrap a cross-toolchain. Throw in the unpredictability of the Kernel version and you get more steps in the process and more chances for mistakes.
The author's comment actually supports Ulrich's position that a proliferation of configuration options are bad since they introduce complexity and difficulty in maintenance. This position actually motivates many of his design choices.
I see that Carlos has already commented about the website.
Someone recently asked the same question regarding releases and I added the following response on the GLIBC wiki:
glibc/wiki/Feedback
Using -r glibc-2_8-branch (branch) instead of -r glibc-2_8 (tag) will probably be cleaner.
As Plouj indicated, someone recently set up a git mirror of CVS HEAD which I use every day for quick checkouts:
glibc/wiki/GlibcGit
We get a lot of people asking question in IRC about their LFS build issues. Hopefully these people are contributing their findings to libc-help@sourceware.org and back to #glibc on freenode.
The release-cycle issue is complicated. In the eyes of the core developers, the responsibility of releasing and maintaining GLIBC releases would require an effort by someone interested in meditating the desires of the Linux distributors. This person would be an experienced developer who would check-in backports of already upstream patches that are in use by one or more Linux distributions in production or beta releases.
I'll put together some notes I got from Roland on how this process should work and post it on the GLIBC wiki sometime in the future.
Regards,
Ryan S. Arnold
ryan.arnold {at} gmail {dot} com
Maybe Uli is just overworked and needs help, so he's frustrated. I definitely don't agree with the attitude "releases are a waste of my time, deal with it" though, when a simple call for help might just as easily get the job done and satisfy the users. Especially for such an important work as glibc!
I'd be truly frightened to run a glibc built from some guessed-at CVS tag in production. Very disappointing!
I've been thinking about this more overnight. I do not believe that CVS is an acceptable release mechanism, even though it has now been usefully documented on the glibc project page (thanks for doing this, by the way!)
Here's why.
Can't you switch to something sane, like FreeBSD?
With the added benefit the license is business friendly.
I'd like to know how many people chose Linux over FreeBSD for *technical* reasons, and not marketing hype.
I had much the same feeling when I discovered that the glibc maintainers had decided not to publish tarballs any longer. Taking matters somewhat into my own hands, I decided to start publishing new ones myself -- you can find them at:
http://toolchain.freesa.org/
Additionally, I have created git repositories based on the sourceware.org CVS repositories for glibc and binutils; I synchronize them every few days, and will also be synchronizing the 2.9 branch from CVS (which the git-cvsimport didn't actually find, so it has to be done manually). Those git repositories are available at:
git://github.com/bneumeier/binutils.git
git://github.com/bneumeier/glibc.git
git://github.com/bneumeier/glibc-ports.git
To the best of my ability and knowledge, these are accurate reflections of the upstream CVS repositories.
If you, or anyone else, would like to use these tarballs or git repositories, you are very welcome to do so!
Oh! Forgot to say. In case you hadn't noticed, glibc 2.9 was released a couple days ago, and there are tarballs for it there as well. The 2.9 branch doesn't exist in my git repositories yet because I haven't got around to it -- soon it will be there!
Thanks for making the effort to do this. It is a valuable service.
However, I am still very uneasy about accepting code form anything except the official glibc project!
I'd also suggest that you should be running this with a set of automated scripts, so that your mirror is always accurate and up-to-date, rather than relying on you manually syncing when you get around to it!
Thanks again.
Automatic synchronizing of my git clone is a fine idea, I'll set that up when I get around to it :)
About feeling uncomfortable trusting anyone who is not an official member of the glibc project -- I totally understand! In fact when I started putting together these release tarballs, I asked on the glibc mailing list how I might be able to get access to ftp.gnu.org so I could create "official" release tarballs. But they shot me down entirely saying that "the glibc community" had decided that tarballs are stupid. So ... *shrug*
Post a Comment