Slashdot Mirror
GNU Libc 2.1.3 Released
Kaz Kylheku writes, "Ulrich Drepper just posted an announcement to the libc-alpha mailing list that the tarballs are out.
This release fixes bugs in diverse areas and improves the stability over last September's glibc-2.1.2 release.
The main archive for this is here and it is sure to
go out to mirrors like wildfire.
Get it, install it, run it---today! "
I've uploaded the 2.1.3 release of glibc to
.gz)
,-. 1325 Chesapeake Terrace ,-------------------' \ Sunnyvale, CA 94089 USA
ftp://sourceware.cygnus.com/pub/glibc/releases
There you can find the files
glibc-2.1.3.tar.bz2 (also
glibc-2.1.2-2.1.3.diff.gz
glibc-linuxthreads-2.1.3.tar.gz
There is no new crypt add-on since it hasn't changed.
This release fixes many bugs in all parts of the library and everybody
is encouraged to update. Preferably through your distribution
provider since compiling glibc yourself means taking a risk unless you
know exactly what you are doing.
This release should be fully compatible (both directions) with glibc
2.1.2. The only part which changed is the format of the files
containing the locale data. This can be easily fixed by running the
`localedef' program for the locales which get used on the system (or
by running `make localedata/install-locales' to update all of them).
--
---------------. drepper at gnu.org
Ulrich Drepper \
Red Hat `--' drepper at redhat.com `------------------------
TO answer your question: most operating systems implement their own C library because they are proprietary. The developers of one OS do not cooperate with those of another OS.
The GNU Libc does support operating systems other than Linux; it is compilable across multiple architectures.
There is a lot of stuff other than standard C that is implemented; a library for a UNIX-like system must implement the POSIX interfaces as well as The Single UNIX Specification.
A C library is typically written using the C language, but with platform-specific extensions and tricks. Obviously, the system call mechanism that is used to interface with the system can't be written in C. Certain assumptions about the hardware are made here and there. (Consider implementing stuff like , or printf conversions, etc).
C libraries are not fully debugged after years of development because they are large, and the standards are moving targets. In the case of glibc, it's actually not that old. From what I understand, glibc2 is a rewrite of glibc1.
I suspect that proprietary libc's are more stable because they have been around longer. But they acquire new bugs when they implement new UNIX features.
The quality of a library implementation is critical to system stability, and in some cases performance as well. Obviously, those library funtions that are basically thin wrappers around operating system calls don't impact performance much. On the other hand, there are areas where optimizations can make a huge difference: things that come to mind are DNS resolver functions, the stuff in .
I understand that the priority needs to be a stable C library, and that the other stuff is really so much frippery, when you get right down to it. On the other hand, I would find it almost impossible to imagine two fairly significant bits of code requiring -NO- updates or touches for such a large leap in versions.
I've not plowed through the entire 2.1.3 sources to see how much of this old code they've simply rolled in, but I don't see any READMEs or notices in the glibc directory declaring the files as obsolete, either.
This is NOT a complaint. Ok, well, maybe it is. I simply think it'd be nice if related software could be kept in sync, with either versioning or notices stating that.
PS: Last distro to upgrade is a rotten LinuxOne!
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
A month after Debian freezes, we're seeing long-awaited major new revisions of various pieces of software (libc being the least notable) Did one of the founders of Debian anger the gods of the Internet or something? :-)
/usr/share/doc/libc/README.Debian.gz makes a lot of comments about 'new CVS checkout', so this might not be far from where we are..
Luckily, the package-pools stuff will supposedly get this stuff into a 'semi-stable' distribution posthaste, although I'd be a little nervous about throwing a new libc in. [1]
Daniel
[1] OTOH,
Hurry up and jump on the individualist bandwagon!
However, all of that massive feature-set support and backwards compatibility and cross-kernel compatibility incurs a cost; doing a stat() is no longer just a system call, but instead has to pass through a layer of glibc code to convert whatever the kernel's struct stat du jour is to the glibc "standard" format. And symbol versioning, while extremely useful, adds complexity and latency to the start-up of processes which link against glibc (i.e. EVERYONE).
Linus has commented a few timees that glibc is a little too heavyweight for his tastes; others have noted that, while the Linux kernel's fork() rate and latency are incredible, it's the ld.so complexity and latency that kills us on exec()s.
I have often pondered a project to parallel glibc, called "tlibc" - the Thin C Library. This library would have to be compiled against the kernel it expects to run against; what's more, apps would then have to be compiled against the newly compiled tlibc, because it only guarantees source-compatibility (and that only so long as kernel interface structures don't change in fascinating and difficult-to-handle ways).
Sure, it would be a PITA to develop such a system, but imagine it in the context of a distribution... let the applications come as close to the "raw iron" of the kernel as possible to eek that extra 3% performance out of Apache/Samba/etc. Remember, most production systems pick a distribution and stick with it, WITHOUT DOING ANY NON-SECURITY UPGRADES, for a long time. This could actually be plausible.
Then again, maybe it's just pipe dream. I dunno.
Hey, the glibc people WARNED the world that glibc 2.0 was unstable.
It's not their fault, like you make it out to be, that distributions like Redhat included glibc 2.0, only to find out that glibc 2.1 broke binary compatibility.
Stick with Slackware if you want to avoid that sort of problem. Everyone snickered at Slackware, saying "it's so backward" because it didn't "upgrade" to the new, unstable library...
Now the glibc 2.1 series is out, marked "stable", Slackware is fine, and the Red Hat 5.x boxes are having problems with libc.so.6 (from glibc 2.0) not working like libc.so.6 (from glibc.2.1). Who's snickering now?
$ rpm -qa | grep libc
glibc-devel-2.1.3-6
compat-glibc-5.2-2.0.7.1
libc-5.3.12-31
quake2-3.20-glibc-6
glibc-2.1.3-6
And I haven't even downloaded anything today!
See you, space cowboy...
to the GNU libc team.
Writing a libc is a horribly fastidious job. Perhaps not as technically hard as writing a C compiler like gcc, but probably far more tedious. Making everything reentrant, maintaining nitty-gritty compatibility with the standards, trying hard not to break everything with each release, this is a very hard job. Remember, for one thing that the headers must compile with gcc -O6 -Wall -ansi -pedantic -W -Wstrict-prototypes -Wcast-qual -Wpointer-arith -Wwrite-strings and this isn't really obvious. Also consider the important aspect of namespace pollution which must be avoided at all costs.
The GNU libc is a fantastic thing. It beats the hell out of the old libc5, which I found mostly worthless. It does a wonderful job of respecting the standards (just look at the features.h header file for an idea) while at the same time providing its own features when they seem useful. And it is very efficient. The documentation is very good, also (very complete, while at the same time very readable; and lots of examples too), even though I detest this texinfo format.
Also remember that a good part of the GNU Hurd is actually in the libc, since it takes care of communicating with the daemons of the Hurd and providing the interfaces (representing depth) that simulate Unix behavior.
ELF symbol versioning is another great thing that was introduced with version 2.1 of the libc. Not to mention things like IPv6 support and so on. In fact, I find that the libc is definitely ahead of the kernel (consider the case of the getcontext() function, which the libc has support for, but tthe kernel is still lacking.
The GNU libc plays an essential role in making our OS what it is. It gets far less attention than the kernel (because of its “cathedral” development model), but it is just as important (remember: a well-written program never sees the kernel, it only sees the libc; the libc is what keeps Unix united, and it can even achieve binary compatibility), and the GNU libc programmers certainly deserve praise for what they are writing.
So, congratulations to Andreas Jaeger, Ulrich Drepper and all the others.
It's sad that ANY comment could conceivably fit each category
-----------
"You can't shake the Devil's hand and say you're only kidding."
1) People complaining that announcements should be on Freshmeat, leave them there...
/. , since that certainly falls in the news for nerds that should be widely spoken... I also have problems with the amount of 'no good for anything I do' programs on freshmeat, though I'm very happy that a resource like that is there... but I won't check it every day... or even every week, since most of it just doesn't apply... /. Maybe they should be a section that you can opt out of, but by default, they should be shown.
2) People complaining about those people, saying that 99% of the stuff on Freshmeat doesn't apply to them, but major releases like libc, XFree, Kernels, do, so keep listing it here...
3) People complaining about troll moderation for #1
4) More complaining that we should have a new section for these sorts of things...
5) People complaining that this isn't new...
6) People complaining about all of the complaints 8^)
and soon...
7) People complaining about me 8^)
I maintain that kernel releases, major X announcements, and other key components (GCC, Glibc, etc) should be announced on
Major announcements should be done on
Even though this is a x.x.1 increase, it *has* been quite some time, and *is* a fairly major step. If every day we got the libc-digest posted here, I'd start to worry, but if the last update was in September, and this interval is too often for you to handle it... (you're creative enough to figure out what I was thinking here, I'll bet)
"It's tough to be bilingual when you get hit in the head."
I, like you and unlike others here, don't believe that software upgrades should only be posted on Freshmeat; the occasional upgrade is very nice to have here, where it has a better chance of getting a more lively discussion if people would actually TALK ABOUT THE SOFTWARE rather than complaining that it doesn't belong here. Almost no one posts comments on freshmeat. If fm had a more interesting and populous forum, I would also prefer to leave upgrades there.
/.er who stated that people who anticipate and acknowledge that they will probably be moderated down should get what they ask for. Don't ruin an otherwise insightful post by claiming to be some kind of martyr.
Note however, that if I still had my moderator status, I would have moderated you right down to 0 from 1 where you are already. I very much agree with the other
JD
Even very stable releases of GLIBC can cause major problems when you upgrade wantonly. This is the one package (for RedHat users) that shouldn't be upgraded unless you really do know what you are doing. I would be *very* cautious until vendors start including it in things like RawHide.
:-)
The issue is that almost all programs on your system depend on glibc. This is about the only library about which such is true. Also the glibc people are infamous for binary (and hell, source too) incompatibility...even between minor versions. In addition it sounds like most of the gains are stability. If you end up screwing your system over...you haven't increased stability much, eh?
Just watch out
-nullity-
I am nothing.
Come on.
:P
/.
/. for about a year and these have always been here and I like them and its just a part of /. sooo stop it :p
/. has been posting software upgrades like this for all eternity. I mean they dont report things like Frog0.0.1 First Release
I happen to enjoy reading about what others have to say on the software that is "important" to the community. glibc IS important
Ive learned a WHOLE lot by what other people have said here at
Please do not go bashing saying this belongs at FM
Been reading