This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
To: svlug@lists.svlug.org Subject: Re: [svlug] Mandrake 8 beta thoughts From: Rick Moen <rick@linuxmafia.com> begin Drew Bertola quotation: > Can you be exact to what is broken in "2.96?" Once again: C++ object-file compatibilty (with code from both earlier compilers and the eventual 3.0 release). Also, choking on some valid C++ constructs. There are, additionally, sporadic but ongoing reports of clean _C_ code erroring out on "2.96" but not 2.95.2, 2.91.66, etc. http://linuxtoday.com/news_story.php3?ltsn=2000-10-07-009-20-NW-SW-0012 Not to mention that version-numbering, which they should not have done. (There is no v. 2.96, and now there never will be.) Other distributions have been equally guilty of such things in the past, such as Debian's so-called glibc 2.07. But that doesn't excuse it. Maybe 2.95-rh1, following the example of version foo-ac kernels? 3.0-pre1-rh? http://linuxtoday.com/news_story.php3?ltsn=2000-10-09-005-21-NW-CY-RH http://linuxtoday.com/news_story.php3?ltsn=2000-10-07-009-20-NW-SW http://www.trolltech.com/products/platforms/gcc.html A good statement of the (compelling) reasons _for_ "2.96": http://lwn.net/2000/1005/a/rh-tools.php3 I'm sympathetic to the need to drive forward and properly test gcc (and glibc 2.2, and kernel 2.4.x). Aside from the version-numbering, I _think_ I'm on Red Hat's side, here, maybe: They're showing necessary leadership. But people should be warned of potholes (and of the option of using "kgcc" on stock RH7 -- and of making it the default compiler). There's also the problem for publishers and users of proprietary code: There are now two x86-Linux target binary platforms (where C++ is concerned). Should publishers target both? Or one, and, if so, which? Or eschew C++ shared libraries (perhaps the best choice, overall)? (In fairness, the C++ binary interface has never been very stable. Ironically, in the long term, RH's move will help stabilise it.) === Date: Wed, 7 Mar 2001 15:09:56 -0800 (PST) From: "Dagmar d'Surreal" <dagmar@dsurreal.org> To: Drew Bertola <drew@drewb.com> Subject: Re: [svlug] Mandrake 8 beta thoughts On Wed, 7 Mar 2001, Drew Bertola wrote: > Dagmar d'Surreal writes: > > > > I'll add one. > > > > 7) Uses the ill-advised "2.96" version of gcc, meaning anything that was > > compiled with anyone else's compiler that you try to link into things > > build with it are almost guaranteed to explode. > > Can you be specific? Can you be exact to what is broken in "2.96?" > What should be avoided? Kernel compiles? Certain module compiles? > C++ cross compiles? What? > > What troubles have you seen with gcc-2.96? The same ones mentioned by the gcc developers about a week after RedHat released it. They specifically mentioned that if you have problems building anything with a version of the compiler that called itself 2.96, that you should be ashamed of yourself and won't be getting any help from them. (Well, not in those exact words, but the meaning was clear) Some specific problems have to do with changes to the way symbols are stored and handles in libraries. For example, if you have a static library that was built with 2.95.2 or egcs, or some other NON-EXPERIMENTAL NON-CVS version of gcc, and you attempt to link it into an application you compile with gcc-2.96, it will generall segfault and die the moment it makes the first call into that library, if it doesn't just explode into a bunch of pointy fragments during the linking (more common with shared libraries than static ones). (And while some people will claim that these incidences are few and far between, I have already run into one case, and the point of having these libraries is so they can be changed without having to rebuild the entire system.) Furthermore the gcc team even went so far as to say that there was a good chance that the way symbols are handled might be changed *again* in a manner that would introduce binary incompatibilites with 2.96 so that expecting the rest of the world will eventually "catch up" to RedHat's compiler was a seriously flawed assumption. If they'd had any sense, they would have simply waited for 2.95.3 to be released. The Debian people don't seem to have a problem with waiting for it, and I'm guessing that Volkerding doesn't have much of a problem with waiting for it either, since the 2.95.3 version is currently in slackware_current, which is known to be quite volatile and subject to change at any time. It seems to me that RedHat's problem is the likely the one they almost always have... Somone from marketing sets a deadline, and forces the engineers to meet it, no matter what the cost. Right now for a reasonably solid and secure box, one needs to be using a 2.2 version of glibc, which breaks the hell out of gcc-2.95.2. The gcc guys seem to have the bugs worked out of the x86 side of things, and it looks like the only reason they haven't released 2.95.3 officially yet is that most of the other important platforms fail the crucial torture test for gcc miserably still. It's just a matter of being patient... which isn't exactly a familiar concept to people who primarily focus on meeting short-term revenue expectations to keep stockholders happy. ===