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! "

4 of 91 comments (clear)

  1. ann by Anonymous Coward · · Score: 5

    I've uploaded the 2.1.3 release of glibc to

    ftp://sourceware.cygnus.com/pub/glibc/releases

    There you can find the files

    glibc-2.1.3.tar.bz2 (also .gz)
    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 ,-. 1325 Chesapeake Terrace
    Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
    Red Hat `--' drepper at redhat.com `------------------------

  2. Updates... by jd · · Score: 5
    Ok, let's get this right. Glibc is up to 2.1.3. Linuxthreads is up to 2.1.3. The crypto extensions haven't been touched since 2.0.111, and the locale stuff is waaaay back at 2.0.7pre3.

    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)
  3. Congratulations by David+A.+Madore · · Score: 5

    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.

  4. Re:Go ahead by Pike · · Score: 5

    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.

    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 /.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.

    JD