Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
GNU is Not Unix

GNU Libc 2.1.3 Released 91

Posted by Hemos from the better-faster-smoother dept.
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! "
This discussion has been archived. No new comments can be posted.

GNU Libc 2.1.3 Released More

GNU Libc 2.1.3 Released

Comments Filter:

  • FM? (Score:1)

    by Anonymous Coward
    Fresh Meat?
  • What was wrong with a.out format?

  • Re:Efficient? (Score:2)

    by Anonymous Coward
    Let's see:
    However, all of that massive feature-set support and backwards compatibility and cross-kernel compatibility incurs a cost;
    Backward compatibility adds some cost, yes. glibc 2.2 has the configure option --enable-kernel which tells the build process to not add code for kernels before the version you named.
    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.
    Only true for kernels before 2.3.35 when not using the LFS interface. Means, you can already avoid it.
    And symbol versioning, while extremely useful, adds complexity and latency to the start-up of processes which link against glibc (i.e. EVERYONE).
    The cost for symbol versioning are almost unmeasurable. Hardware effects are for more visible.
    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.
    This is not a libc problem in the first place. I'm working for a long time already on a version of the binutils which then can be modified to spit out an extended ELF format which allows quicker startup times. But since this is a off-time prject and since there are some other little packages I have to care about, progress is slow.

  • ann (Score:5)

    by Anonymous Coward on Friday February 25, 2000 @04:12AM (#1246975)
    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 `------------------------

  • New != better.

    I am happy that the crypt() code needed no changes - this indicates that it is stable. Stable crypto code = good.

  • You might consider picking up the small, free Cygnus C library as a foundation. It is intended for embedded use, and is also the foundation for the Cygwin Unix emulation for win32. Thus, it should be both light weight and relatively complete.
  • The GNU C library is used on Linux and Hurd, and earlier versions also worked on SunOS. This was useful back when Sun didn't have an ANSI compliant C library.

    It implements many standards, apart from ANSI/ISO C also various Posix and Open Group standards.

    It will never be completely debugged, since both the standards and the underlying OS'es keep changing.

    It is written in GNU C.

    It's effect on performance depends on what you do. It can range from "none" to the only significant factor, depending on how much your application uses library functions.

  • Re:Feed Me Signal (Score:3)

    by Kaz Kylheku ( 1484 ) on Friday February 25, 2000 @06:39AM (#1246979) Homepage
    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 .

  • Updates... (Score:5)

    by jd ( 1658 ) <`imipak' `at' `yahoo.com'> on Friday February 25, 2000 @04:26AM (#1246980) Homepage Journal
    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!

  • 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? :-)

    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, /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..
  • With the relaxed US export restrictions, could it be included in the regular package?
    To the best of my knowledge, no. I believe that the source code export restrictions have not been removed. Binaries only. Good for M$, good for NS/AOL, not good for us.
  • Any stability improvement with Java turned on?
  • Glibc 2.1.3 is on my Potato system so I see no need of complaining.

    I have found that Netscape works much better with this libc than 2.1.2. No mysterious crashes when closing Netscape windows.


  • Have you tried to get the tarballs today?

    Good luck.

    The dang place has been overwhelmed !

    Oh boy !!

  • There was a notice in one of the 2.1.x releases a while ago that stated the locale stuff was no longer needed as it's included into the main library. Perhaps that notice has been removed, since its assumed most people have upgraded already.
  • 0:27 GMT-6 it's working.
    I've just downloaded the 3 files.

  • Re:Updates... (Score:4)

    by grahamm ( 8844 ) <gmurray@webwayone.co.uk> on Friday February 25, 2000 @04:52AM (#1246988) Homepage
    There is no longer a separate locale file, it is incorporated into the main library. As an aside, you will have regenerate your locale database when upgrading to glibc 2.1.3.

  • Efficient? (Score:4)

    by artdodge ( 9053 ) on Friday February 25, 2000 @06:26AM (#1246989) Homepage
    At some things, yes.

    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.

  • Comment removed based on user account deletion
  • I remember when we had to imagine a guy who was thinking about using an abacus. We'd have to do metamath using the imaginary abacus, in the mind of the imaginary guy to get our work done.

    LK
  • On re-reading, again, I see that part of what I just wrote is unclear.

    When I refer to October GNOME, I mean that Red Hat should have waited for that release. I don't mean that October GNOME is unfit for production use.
  • Oh, I don't mind bugfixes at all.. I love them, in fact.

    The problem is, upgrading a Red Hat 5.x box to glibc 2.1 (now standard in Slack 7) is impractical, because of the soname issue. (libc.so.6 vs. libc.so.6). If Red Hat had heeded the glibc unstable warning, in the same way they heed the kernel unstable warnings (2.2.x vs 2.3.x), I'd be happy.

    You see, since Slackware stuck with libc.so.5, upgrading to glibc 2.1 is relatively painless (the transition can be made gradually, first with new apps, then recompiling/reinstalling the older stuff), because the sonames are different.

    Glibc developers aren't to blame, because they left the soname the same, while breaking binary compatibility. You weren't supposed to be using the unstable library in a production box, anyway. Red Hat just got too "cool" and jumped the gun, in the same way they loaded on GNOME far before it was really ready for use (October GNOME).

    This reminds me of the inflammatory emails linux-kernel gets, when people whine that some internal structure changed, and that linux will never be "professionally trusted" if they keep breaking things.

  • Re:***WARNING*** Upgrade with caution! (Score:4)

    by JamesKPolk ( 13313 ) on Friday February 25, 2000 @05:13AM (#1246994) Homepage
    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?
  • It's true - That's what freshmeat is for (and IMHO not slashdot).

    How about adding another section (to accompany apache, askslashdot, etc - maybe called "releases") so that people can filter the stories out a bit easier.

    Just my 2 cents.....
  • This is one of the more "Insightful" posts I've seen on /. in a long time!

    Create a section for semi important software releases on /. but leave most for freshmeat.

    And, by all means post really important SW releases on the main page.
  • Yeah.

    As much as I loathe M$, Why2k is rather relevant but Gadget 4.0.3pre42.alpha is not....
  • Hey,

    Please set your system clock to todays date. We can not allow people to download tomorrows software today :-D

    Seriously, it seems as if there is a version numbering problem....
  • This post is perfectly valid!
    AC is suggesting in two words that this whole article belongs to freshmeat.org.
    I do actually agree! I want to see XFree86 4.0 and other major releases on /. otherwise I think they belong to freshmeat.

    The "troll" moderation is grossly unfair and I would like to point people that do moderation to sid=moderation [slashdot.org]
  • I think it's a shame that crypto is still a separate add-on module. With the relaxed US export restrictions, could it be included in the regular package? There could be a --nocrypto configure option for people building French distributions.

    It just seems that it makes life easier for almost everyone if they're one package. (Imagine if the Linux kernel was distributed separately from all the device drivers...)
  • no support for shared libraries

    all your foo.so files are ELF, as are the executables that use them

    .a files IIRC are pre-compiled statically linkable binaries, in a.out format

    We are all in the gutter, but some of us are looking at the stars --Oscar Wilde
  • Slashdot-powers-that-be, please add this '(GPL) releases' category.

  • How new? (Score:3)

    by rmull ( 26174 ) on Friday February 25, 2000 @04:08AM (#1247003) Homepage
    $ 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!
  • Wibble! Since when was snickering good? Since when was Slackware something to gloat about over and above RedHat?

    Being cutting-edge is intrinsically good; if you can't put up with the occasional bug and fix coming rapidly along, go back to another OS, thou evil troll!
  • "RedHat just got too "cool" and jumped the gun"

    Yup, that's always possible.
    I'm hardly a RedHat fan, for all I disagreed with the "slackware v RedHat" in the original comment.

    "...linux will never be "professionally trusted"..."

    Eeek, that argument is so bogus it's unbelievable. "Professionals" either aren't being professional, or are just being lusers if they can't cope with the occasional fix.

    Me, the way I operate is at the cutting edge of Debian "unstable" - not "potato" or "frozen", the real unstable thing. I apt-get dist-upgrade every day as a matter of course; and I have to wangle things to get packages to install, such as hacking /etc/init.d/devpts.sh, or whatever. I get the impression there are folks out there who aren't suited to doing this kind of thing... RedHat's errors were (a) in targetting that kind of, er, "user" (I believe they're called) and (b) not living up to the stability thing. Either way of looking at it it could be seen to be "broken".

  • The GNU C library (version 2) only supports Linux and Hurd as kernels, as far as I know. Some README file somewhere says that porting it to other OSes should be an easy task, but it looks like it hasn't been done.

  • Congratulations (Score:5)

    by David A. Madore ( 30444 ) on Friday February 25, 2000 @06:02AM (#1247007) Homepage

    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.

  • As an addendum to this:
    for versions of glibc -prior- to 2.x (I think it
    may be broken in 2.0 as well, but I don't recall what the results of the testing were), the aforementioned behaviour didn't exist.

    This -has- been verified by using different glibc versions on the same machine, and using different glibc and C library versions on different operating systems (AIX, FreeBSD, NetBSD and Linux were the OS's used for testing this behaviour).
  • There's one bug in particular that I'd like to see fixed, but I don't know how prevalent of a thing it is...*shurgs*
    fork() is/was broken in 2.1.0, 2.1.1 and 2.1.2 for the specific app that it's being used for, and the manner that it's being used is consistent with how it's supposed to work (IIRC).
    *shrug*
    basically: in the case where an app forks off a child process, then returns, and then has another child process fork()'d (each process running the same external app), is it still freezing/not returning from the child cleanly?

    That seems to be the bahaviour, at any rate...
    (source code for the app can be provided for testing of this behaviour).
  • But I do think they should have their own section.

    I know all about Freshmeat, and I read it regularly, but it's full of software that just doesn't interest me. Today I've had to sift through a program to flash Morse code on the keyboard LEDs, a window manager that describes itself as "pointless", and a whole lot of programs for manipulating my non existent MP3 collection in previously unimagined ways. I don't mean to bash these programs in particular. I'm sure they're good at what they do, and that the authors have put a lot of hard work into them. I'm afraid they just don't interest me.

    The software that appears on Slashdot is the really important stuff (IMO): Linux kernels, C libraries, X servers, etc. I like to hear about it on Slashdot. When we start seeing "Yet another HTML preprocessor 1.2.1.1" on the front page I'll complain as loud as everyone else, but until then I'll be happy.

    Perhaps the real problem is with Freshmeat?

    Love
    Molly
  • Moderate me down.

    I'm not complaining that this was posted on Slashdot. Slashdot can post whatever they'd like. But it doesn't belong under the GNU heading. It, along with all the development kernel releases, and the new versions of XFree86 need to have their own section. I, like a great many people here, read Freshmeat precisely for this sort of thing. I understand that some things deserve to be posted here on /., and all I'm asking for is the ability to filter them out.

    -----------

    "You can't shake the Devil's hand and say you're only kidding."

  • Fair enough: I think the reason that I, and a lot of other people, put comments like that in their posts is out of frustration with idiot moderators.

    It's like saying "Yes, I know you want to moderate me down. Do it, and then go fuck yourself". Maybe a little unneccesary, but it irks me to know ahead of time what a moderator is going to do, based on the subject of my post.

    -----------

    "You can't shake the Devil's hand and say you're only kidding."

  • Yes, major software releases CLEARLY have a place on Slashdot. The only think I complain about is that they don't have their own section. How can I possibly filter out software announcements if they're spread out into every category? This isn't a lot to ask...

    -----------

    "You can't shake the Devil's hand and say you're only kidding."

  • To be honest... I really don't care. Honestly, I don't. But it seems that a bunch of people do mind (you'd be hard pressed to argue that, seeing the posts about /. reinventing FM).

    The reason I argued the point, was because there's an obvious trend on Slashdot now for posting software releases. I think those releases *deserve* their own section, in the same sense that BSD and Apache do. I'd like to be able to create a slashbox for new releases, so I can go discuss them. They have a place on Slashdot, but I don't think it's mixed in with all the other stuff.

    -----------

    "You can't shake the Devil's hand and say you're only kidding."

  • Moderation :) (Score:3)

    by Foogle ( 35117 ) on Friday February 25, 2000 @08:56AM (#1247015) Homepage
    My above post has now been moderated as all of the following: "Troll", "Flamebait", "Overrated", "Underrated", "Insightful", and "Interesting"

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

  • Gotcha...

    I fully agree with what you think are major releases, and I also don't really think that the Stampede code freeze qual'd as 'major'... once it is actually released, maybe... Like "1.0 released today", rather than ".90 coming Any Week Now(TM)"... Considering that you *need* a c lib to build Linux, I'd consider this pretty major... anything that you *need* to run (some people don't need X, but..) Linux/BSD/Foonix/BarSD 8^) Not like "I *need* pine, and version umdiddlysquat.whoosymawhatchis.whatchmacallit is out - YAY!", but legit components of the system.

    My point was that even a 'minor' version increment for glibc is rather *major*... the previous updates were:

    2.0.6 12/29/97
    2.1.1 5/25/99
    2.1.2 9/7/99
    2.1.3 2/25/00

    Not really an everyday sort of thing... I think it deserves a post here. That's all.

    Minor is tougher to define, but I think it's safe to say that it is anything that isn't 'major' 8^D

    Or whatever...

  • So here's the gist of it... (Score:3)

    by Tower ( 37395 ) on Friday February 25, 2000 @05:17AM (#1247017)
    1) People complaining that announcements should be on Freshmeat, leave them there...
    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 /. , 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...
    Major announcements should be done on /. Maybe they should be a section that you can opt out of, but by default, they should be shown.

    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)
  • Just two days after I finally installed 2.1.2 properly.... ;-)
    My, does 2.1.3 also build itself "recursively" on 'make install' like 2.1.2?
  • glibc comes with a manual in texinfo format. Is this manual available somewhere online in HTML format? I know that texinfo 4 can produce HTML output, not to mention texinfo2html perl script. The pointer to a ready-made HTML will be appreciated though.
  • It's funny. A joke. Laugh. Ha-Ha. Come on guys..

  • On Freshmeat, there is rarely any meaningful discussion of software announcements, especially regarding essential components of the system as glibc. There is, however, a plethora of meaningful discussion and insight on Slashdot about important software releases that one is unable to find on Freshmeat. I know I am pleased to find an outlet for mine and others' ideas regarding various things such as X and kernels that, if posted in in Reply to an article regarding, say, Privacy, would be moderated down as Offtopic and consequently not seen by anyone.

    Chris Hagar

  • Re:Go ahead (Score:5)

    by Pike ( 52876 ) on Friday February 25, 2000 @05:08AM (#1247022) Journal
    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
  • Let's compare:
    <TT>
    [billk@cr957697-a billk]$ su root
    Password:
    [root@cr957697-a billk]# rpm -ivh glibc-2.1.3-6.src.rpm
    glibc ##################################################
    [root@cr957697-a billk]# exit
    exit
    [billk@cr957697-a billk]$ diff glibc-2.1.3.tar.gz /usr/src/redhat/SOURCES/glibc-2.1.3.tar.gz
    Binary files glibc-2.1.3.tar.gz and /usr/src/redhat/SOURCES/glibc-2.1.3.tar.gz differ
    [billk@cr957697-a billk]$ ll !*
    ll glibc-2.1.3.tar.gz /usr/src/redhat/SOURCES/glibc-2.1.3.tar.gz
    -rw-rw-r-- 1 root root 8277967 Jan 31 09:32 /usr/src/redhat/SOURCES/glibc-2.1.3.tar.gz
    -rw-r--r-- 1 billk users 9013927 Feb 25 06:44 glibc-2.1.3.tar.gz
    [billk@cr957697-a billk]$
    </TT>
  • Are you using some sort of mindaltering drugs?
    ELF is not GNU, lots of Unices (Like Solaris) have been using it for years. Mainly because only an idiot would attemt to create shared librarys with a.out.
    TeX is not GNU, it was written by Donald Knuth. Never used troff, but I hear it was bad in comparison.

  • I can't see how merely anticipating a post to be moderated down has anything to do with "claiming some kind of martyrship".

    If you are jealous that your posts are not as insigitful as the ones you are reading, fine - think some more before you post. If you feel disgusted about the tone in which people speak, too bad - just don't assume what goes on inside the poster's mind (e.g. "hm...I want to be a martyr") when you reply. It seems very immature to me.

    Sorry I just can't help posting the rant. I've seen far too many "I'll give you what you ask for" posts regarding this matter. You should note that the person is merely anticipating - whether or not they're asking for a demoderation is totally up to your imagination.

  • Re:How new? (Score:3)

    by puetzk ( 98046 ) on Friday February 25, 2000 @04:17AM (#1247026) Homepage
    Some silly distros have been including CVS snapshots, but it's finally released. Get the final version and quit using an alpha release...
  • You're running Raw Hide or Red Hat Linux 6.2 beta 3, aren't you?
    For betas, it's not uncommon (or bad) to ship pre-release code.
  • I agree (for what it's worth) with Mekanix: leave the 0.0.1 updates to Freshmeat. I realize that the two websites aren't really related (they are just owned by the same company), but it would be nice to see some cooperation as that is what Open Source is all about...

  • I'm was using Redhat 6.1 and after I upgrading I got a few errors that flashed by then I locked up and rebooted and hangs during boot with the following error: BUG IN DYNAMIC LINKER ld.so: dynamic_link.h: 49: elf_get_dynamic_info: Assertion '! "bad dynamic tag"' failed! Any RH users successfully update this?

  • ***WARNING*** Upgrade with caution! (Score:4)

    by nullity ( 115966 ) on Friday February 25, 2000 @04:44AM (#1247030) Homepage
    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.
  • Glibc is for wusses. People that use rpm to install packets or gcc to compile their programs.

    Real Men bypass libc and use straight system calls to interface with the kernel. Ha! And none of this weeny C crap either. Everything handcoded in assembly... I remember the days when we wrote our first assembler in straight binary. Nah, forget that, I remember PUNCH CARDS! And running programs in your head because it took two days to pass through the machine!

    libc
    don't make me laugh....

  • Someone inform me. Why do most operating systems implement their own C library? Is glibc compile-able across multiple architectures? Is it merely standard C that is implemented in these libraries or is there a lot of other stuff that needs to be implemented? What is a C library written in? Why are they not fully-debugged after years of development? Are some implementations better than others? How much does the quality of an implementation impact system performance?

    Honest questions.

  • I know this is a direct attack to your argument which I somewhat dislike (singling out a person).

    So I will make this as a suggestion.

    Skip over the articles. It doesnt hurt to see GNU Libc x.y.z is out and just not read it does it? I mean if it does I will complain for you ;-) okay okay thats a little biting im just picking. How big of a deal is it. I know some people cruise FM all day but some of us COME to slash dot to hear what people got to say about software like this.

    If there was a filter for *everything* people wanted hemos and taco would spend all day coding filters! use your brain it filters excellent.. I got so good I could totally ignore my wife

  • *nods* That makes sense. I think I would actually like that to. :-)

  • FM Posters.. (Score:3)

    by jallen02 ( 124384 ) on Friday February 25, 2000 @04:50AM (#1247036) Homepage Journal
    Come on.

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

    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 /. for about a year and these have always been here and I like them and its just a part of /. sooo stop it :p

  • I agree with that major releases should be announced on /., but a couple of what have been announced lately I didn't find major at all.

    For major releases I would think something in the lines of XFree4.0, FreeBSD4.0, Linux2.4 and not all those nightly CVS-builds....

    But I may be wrong, so would someone please explain to me what "major" includes and the difference between major and minor. Right now I don't see any.

    Bjarne
  • BEGIN: cut-and-paste

    Re:ann...crypt add-on

    (Score:-2)
    by NRLax27 on 7:56 25 February 2000 PST
    (User Info)

    If you follow the link in the glibc-crypt.readme on ftp.gnu.org, it brings you to a site that has a 2.1.3 version of the libcrypt addon. Did they just change the version number to match, or is there really a new version?

    END:cut-and-paste

    I don't like the fact that some people now seem to have a default score of -2.

  • Re:Updates... (Score:3)

    by mvs ( 141323 ) on Friday February 25, 2000 @06:43AM (#1247040) Homepage
    No, you haven't gotten this right.

    The lastest crypto patch isn't the one on cygnus' ftp site. The latest one is 2.1.2, which you can find on ftp://ftp.nl.linux.org/tmp/, among other places (search http://ftpsearch.ntnu.no/). The announcement says crypto patches didn't need updating, so you can use the 2.1.2 crypto patches for glibc-2.1.3

    The locale info is now distributed as part of glibc, so it's in the gblic-2.1.3 tarball.

    You see, all glibc-packages *are* up-to-date. And, imho the glibc guys are doing a great job. Glibc is as important and complicated as the Linux kernel. Glibc guys aren't as well known as linux guys though.

    The only problem is that the ftp directory listing is admittedly somewhat confusing. Worse, the ftp.gnu.org ftp site is rather confusing and it holds imho too much outdated tarballs. If someone would clean up that ftp site a bit, it would save quite some bandwidth and diskspace for ftp.gnu.org mirrors.

    Regards,
    Maarten

  • I'd like to see this. That brief description has got me interested. How can I get a copy?
  • I have put glibc-crypt 2.1 on sourceware in ftp://pub/glibc/releases/glibc-crypt-2.1.tar.gz [pub] because people on slashdot were complaining :-).

    5d28eb5376031c4cf7ba6057322852fd glibc-crypt-2.1.tar.gz

    There have been no changes to glibc-crypt since the 2.1 release.

Slashdot Top Deals

Promising costs nothing, it's the delivering that kills you.

Close