Slashdot Mirror
GCC's Response To Red Hat
The GCC Steering Committee has issued a statement on the use of snapshots in distributions. This statement is clearly in response to Red Hat's use of gcc-2.96 in its Red Hat 7 release. They didn't like it very much, and there are compatibility problems. Worth a read. Credits for this news goes to Linux Weekly News.
I agree, 2.7.2 had so many problems, mostly when using the STL. I have some (legal) code for which even egcs 1.1.2 chokes at some places. However, I haven't been able to find a fault (so far) in 2.95.2, except that the fact the standard library isn't complete yet (like the missing stringstream class). Aside from that, I would quialify it as one of the most ANSI C++ compliant compilers around (at least, it's better than HP's ANSI C++ compiler!).
Opus: the Swiss army knife of audio codec
Sorry, my e-mail is mathgod79@hotmail.com. Please e-mail me if you can help.
Debian seems to be ok the newest version in Woody is 2.95.2-15.
Sometimes I'm glad that they take their time before updating to the newest thing.
134340: I am not a number. I am a free planet!
Having had a bad reputation with my local LUG starting distribution flamewars on their listserv, I've tried to keep a slightly lower profile.. But I laughed soo hard when I heard that redhat was shipping *TWO* gcc versions with their distributions, one for kernels (2.91) and one for compiling everything else.
I also got LARTed, and told quite succintly to "Be Quiet" by the almighty moderator of the list.
"Redhat is God, Redhat is right, Do not laugh at the Redhat".
I *intensely* dislike redhat. Redhat users, and more importantly, those who don't recognise the need to criticise the things they love.
I use debian. Debian has shortcomings, and I am quick to critisie if I find something wrong. This is something that alot of linux users really have to learn to do. I've seen so many people brough in by the propganda "Linux doesn't crash" "linux is more stable" "Linux is more up to date".
Linux Crashes.
Linux is horribly unstable.
Linux is REALLY horribly unstable if you decide to stay on the bleeding edge.
Redhat has made some pretty big mistakes. They've got entirely the wrong tack on releasing a distribution, (But redhat is so good!).
No they're not.
I've seen so many editorials and comments from both sides of the fence on RPM, on Redhat's corproritisation and varied other facets of the Organisation.
Redhat will end up giving linux a bad name.
They are adopting a commerical distribution structure.
"We need a new version number!"
(Why not Redhat95!)
I believe debian (and varied *bsd's - I'm not calling debian the be all and end all) has a much cleaner and neater release structure.
We have "Tried and True" "Getting there" and "Horribly Unstable". If you *want* to have all the latest crap, you can run *horribly unstable*. And we're more than happy to advertise that it WILL quite probably screw up your life, get your dog pregnant, and make your fridge say "ZOOL!".
Redhat, on the other hand, will take all the most horribly unstable packages, wrap 'em up, make sure they install properly, and put 'em on a CD.
This is exactly what happened with gcc 2.96 (We can't just put gcc 2.91 in 7.0! We'll be behind!)
Steve.
sjthorne@ozemail.com.au
Of course I can defend it - technically, it was the right decision and I still think we should have done it. We needed the features (like actually working, and support for multiple platforms), and as probably the only company have the inhouse expertise to stabilize it. The C++ compatibility issues are far less important - as C++ has never been compatible anyway.
What we did wrong was not communicate our intentions better to the steering comittee.
Releasing a "blessed" gcc (if not looking at our compat-compilers which are egcs 1.1.2) is of course not going to happen - they wouldn't be compatible, and the reasons we had for choosing to do what we did are still valid. We did the right thing, and in so doing improved the current state of gcc a lot. Be happy.
What compiler does?
Well, I don't think RedHat needs to work on the current rev (2.96) snapshot further, if that's what you mean. The 2.96 snapshot that ships with RH 7.0 works pretty well.
Stephen Molitor steve_molitor@yahoo.com
This isn't the first time RedHat has released a non-stable branch compiler. I code for an IRC bot project, and we couldn't figure out why it was crashing on redhat systems in chunk_alloc(the low level call made by malloc) It turns out that RedHat 6.x uses a version of GCC that 'does not exist' like the redhat 7 one, and that was the cause of the problem. Turning off all compiler optomisation on redhat systems fixed this problem. I don't see why redhat is making the same mistake yet again, who knows what is broken in this compiler? This time it could be somthing worse than malloc() and friends randomly failing in compiler optomised binaries.
I could have sworn so, but then again I get brain-fade occasionally just like anybody else.
-- Post No Gravy
You're right that glibc compatibility is more important, and I am hoping and praying that Ulrich Drepper doesn't see fit to make any changes that break compatibility between glibc 2.1.94 and glibc 2.2 (since RedHat released a pre-release beta snapshot of glibc as well in 7.0). I've asked on various mailing lists, and I worry that Ulrich has conspicuously not pledged not to make any compatibility changes. Shiver
Still, there are quite a few applications that are written in C++, and like it or not, ABI compatibility is going to get more and more important as more and more people outside the traditional Linux user base reach out and start using Linux. This is a good thing, but it means we have to be more careful in what we release, going forward.
And I'm sorry if people think I'm picking on Red Hat. I still use Red Hat on most of my machines, and I've been using Red Hat since its 2.0 release. I'm a stockholder of Red Hat, and I have many friends who work there. But to the extent that Red Hat is a market leader in the U.S., it means that its responsibilities are greater, and it needs to be held to a higher standard --- just as Microsoft has to be held to a higher standard because it is also in a dominant market position.
Yeah, Objective C support is somewhat broken. GNUstep won't compile (Internal Compiler Error). Still not sure why yet.
You just can't link to shared libraries that you don't control.
Sig goes here
Minor correction:
:)
We compiled the latest KDE2 CVS stuff with egcs 1.1.2 a couple of days ago.
I won't comment on the rest.
Not "Every" distro..
Debian, Slackware and RedHat however have.
(The Debian CD I tried to install required so much information from me it seemed I'd need 5 years experence with Debian before I could ever get this stupid CD to install)
It depends on how cocky the distro people get.. Mandrake screwed up day one.. it took Slackware and RedHat years to make the same kinds of mistakes.
Debian seems to go overbord trying to PREVENT similer mistakes and end up bombarding the user with questions he can't answer. (the inverse extream)
But at one time RedHat and Slackware had a clean history...
It happends to them all.. the key is to GET ON THEM ABOUT IT.
Slackware wouldn't upgrade to glibc and they lost users over it.. They were not forgiven. They fixed the problem.
You forgive them they won't do anything...
So beat RedHat up over this.. Back off ONLY when they fix it...
If someone else pulls a stunt.. beat them up over it as well...
I don't actually exist.
However, a lot of things are just not ready yet, in particular the 2.4 kernel, and just behind that, gcc 3.0. For me, KDE 2 is also coming soon, but that's probably not too important to you Gnomers.
Amazingly, the simple answer is to release Redhat 6.3 with stable versions of key software. When the 2.4 kernel and hopefully gcc 3.0 is ready, then do a Redhat 7.0. Presumably, that is just a couple of months away, and would be much more popular. The current Redhat 7.0, as any other new version, updates lots of packages, but the instability in key software is not a good thing.
I asked a friend of mine (in kernel development) who worked at Red Hat, because I was concerned about the use of the prerelease glibc, and I was told, oh, don't worry; it's just a beta, if there are too many problems, or if the final release hasn't been released in time, it'll get backed out. So I held my peace. In retrospect, I probably should have pushed this issue harder with other Red Hat contacts at the time.
So yes, it wasn't a complete surprise, but I was still disappointed how many prelease snapshots of many major packages (XFree86, glibc, gcc, etc.) were in the 7.0 release.
If you change the "cc" symlink to point to "kgcc" instead of "gcc", the kernel builds fine on RH 7.
Having spent hours trying to find bugs in my code that turned out to be gcc 2.95.2 bugs I'm glad *something*'s being done about it. The 2.96 snapshot thus far is much better quality than 2.95.2, if a lot pickier on ANSI C++ violations (which is fine too).
Hah, when I read that announcement, I about laughed. After I read that, I was thoroughly confused as to what they were doing. Why would they using such confusing names and then release...and then change the name in order to lessen confusion, while the new name was just as confusing...with the same problems and no upgrade. Oh well, I say their fault for the problem, if they are mad about the confusion, they should learn to change it to something better.
The reaction of the GCC steering committee makes sense, given the developmental status of 2.96. I would certainly avoid it for anything that had to have high reliability. I would have bundled a stable release (2.95) and provided some means of downloading 2.96 for the thrill-seekers out there. I know 2.95 has less than perfect support for the standard, but that doesn't justify pushing people into 2.96.
Gorkman
Let's see... we don't have GCC 3.0, Linux 2.4.0 or KDE2 yet. This sounds to me like a perfect opportunity to release RH 6.3 - use updated versions of all the old trees, no incompatibilities, where's the problem?
Instead, the managers / marketing execs decide "oh no! we need a 7.0 release" and the techs have to scramble to get something that *looks* like a major upgrade. Bad news.
Red Hat's x.0 releases have a bad track record. I specifically avoided downloading RH 7.0 for that very reason, even before I heard about the bugs. Even in 6.2, the "sndconfig" scripts were horribly broken (at least for my ISA-PnP based AWE64, not a rare card by any means). For my dad's conversion to Linux, I eventually settled on Mandrake 7.1. Not perfect either, but *much* more polished.
As for GCC 2.95.2, I installed that on my RH 6.2 system a while back, and have subsequently compiled kernel 2.4.0-test8 and XFree86 4.0.1 under it - the two biggest release packages I can readily think of. No problems there...
--- The key to knowledge is not to rely on people to teach you it ---
Richard Henderson ignores the issue of binary compatibility with other distributions, and, I believe, overstates the problems with 2.95.2. The Alpha back end isn't great, but ia32 which most folks use was decent and it was the best C++ front end we ever had. And the kernel developers did a lot of work so that at least the Linux development kernels build ok with 2.95.2 -- but "2.96" can't build Linux (gcc problems building the kernel are often kernel, not gcc, bugs, though sometimes gcc is at fault).
Also, Richard is wrong when he says that their "2.96" is compatible with the forthcoming 3.0 at the source level. It isn't; it still uses libstdc++-v2 (the v3 library is not complete). Streams aren't templates, the standard library is not in the std namespace. It is compatible with 2.95.2 at the source level, not 3.0.
Even so, I could have accepted his arguments much more readily had they been made before the release and not after, and if they had polled customers and software developers about the issue rather than just deciding internally.
Now, I'm grateful for all the hard work the Red Hat/Cygnus folks have put in. But when different (GNU/)Linux distributions can't run each others' binaries, you have exactly the same situation the Linux company chiefs say they won't allow to happen: effective forking of Linux.
_For the unitialed, NO COMPILER SUPPORTS THE EXPORT KEYWORD AT THIS MOMENT.
Sorry.
Still, they must look pretty silly after this and the 2.4 kernel delay that will probably make 2.4 come out after 7.1 is released. So much for all that preparation to make RH7 2.4 compliant :-)
# debian/rules
Has this burnt anybody yet??? I would be curious of the ramifications of this....
(+1 Funny) only if I laugh out loud.
Three penguins in a row on slashdot.org! That looks really wierd. Good thing the icons in the header don't repeat.
# debian/rules
Where did you get the idea that 2.95.2 is "the buggiest release of GCC since early days"? Have you ever used it? Did you know that it is the production compiler on Debian 2.2 and they are reasonably happy with it? That it had some of the most thorough testing of any GCC release ever?
I've been an active user of g++ since 1990. For C++, 2.95.2 is the highest quality release ever put out. The problems with 2.95.2 are platform-specific, the Alpha port wasn't great. Don't spread false information.
XML?
Your design to a real part online: Big Blue Saw
And don't forget Redhat 5.0, that packaged a compiler that failed on Cyrix' CPU's. IIRC that was also a snapshot, in which RH enabled some vague, not entirely stress tested optimalisations. And those failed on some processors, they seem to never learn
I agree that the C++ ABI issue is a horrible mess, but you really can't blaim AT&T for that. If the C++ ABI had been set back in early days, it would have had to be revised several times over the years as templates, namespaces, and so forth were added to the language. For this to have been any better than the present situation, a much more extensible object file format would have to have been created than we use today.
The real issue is that C and C++ still use a flat namespace for symbols in object files, just like in the 1950's when assembler languages were all that existed. The minor additions made to ELF for static constructors and the like were the absolute minimum to get C++ to work--leaving no option but kludge-of-the-day name mangling to flatten C++'s multitude of hierarchies. This is so inelegant that no one wanted to define it into a standard -- surely a better way will arise? But it hasn't.
CFront's name mangling could have been taken as the de facto standard and extended as C++ was extended. That didn't happen, and given that AT&T didn't "own" C++ the way that Sun owns Java, it probably wouldn't have happened even if they pushed it. But why perpetuate what is an ugly kludge, anyway?
It's probably too late to fix the real problem. Rejiggering the entire toolchain for a new object file format just isn't going to happen. (Some people are still smarting after the change to ELF.) So we'll have to live for the forseeable future with fragile and incompatible attempts to fit N-dimensional structures into flat lists...
How has it hurt the community?
GCC isn't the hurting the community, RH is, using non-stable software in a production environment (new RH release, everyone install new RH) which has known problems.
So maybe GCC is behind, that still doesn't change anything... what RH is doing is wrong, imho
I have no problem waiting for a little longer then normal (geez, just take the kernel for example...it's going to get near one year now) if it means a better release.
-
Has anyone ever stopped to wonder whether redhat did this to CREATE incompatibilities? Redhat is the market share leader. If someone distributes a binary, it is most likely going to be for redhat. What's an easy way to "compete" with other distributions? Make sure that binaries for your linux won't run on other distributions. This forces companies that want to distribute binary-only packages, or packages that are not easy to compile, as multiple binaries thereby confusing the scene. If other distributions follow redhat and use this compiler, well then you've got a situation where redhat is the leader and everyone else is trying to be compatible with it. You've got that already to some extent, but this would make it even worse as distribution developers would have to work to stay RH compatible.
I don't know if this is what redhat is doing, but it certainly is interesting.
Personally I think they've pulled a DOS 4.0.
Lee Reynolds
Muslim community leaders warn of backlash from tomorrow morning's terrorist attack.
RedHat is not putting random version numbers on someone else's software.
Yeah, sure - that was the other stupid answer I could get. Sorry for not predicting that one in my original post.
Did it occur to you that someone with some insight might be able to give a little more detailed answer than that? Like if we are looking at month's or year's of development? Perhaps some key features that are still missing?
Linux 2.4 will also be out "when it's ready", but I am willing to bet that it will be within a year.
--
Yes, RedHat is evil (in this circumstance). Releasing snapshots of absolutely-critical components of an OS is evil. Whatever their technical/marketing reasons for the inclusion, it was irresponsible. Free software should enjoy the same respect of version control as do commercial products. To do otherwise weakens the notion of free software products as being stable, manageable entities, and will lead people to choose products that noone ever got fired for choosing (VC++ 6.0, for example).
It's a matter of whether you believe "the ends justifies the means". Sure, Linux is all about practicality, but I would also like a little discipline in my commercial distro. (that's why I run FreeBSD)
The note says that the gcc steering committee "cannot support" gcc 2.96. So? The gcc team are not in the support business. Red Hat/Cygnus is.
The C++ support in 2.95.2 is absurdly much better than 2.7. Yes 2.7 will compile lots of line noise vaguelly resembling C++, that 2.95.2 will rightfully reject. If you have code written using a "gcc 2.7 accept its, it must be good" mindset, you have my sympathy. You will never get a real C++ compiler to accept it.
GCC 2.95.2 is actually close to being a complete C++ compiler, the major lack is a standard conforming library. Yet, what it has is infinitely closer to the standard than the old libg++ bundled with GCC 2.7. And don't even think avbout using STL with GCC 2.7.
The major thing holding back GCC 3.0 is completing the rewrite of the C++ standard library, which is *not* included with Red Hat GCC 2.96.
What gets me is this: why the mad upgrade cycle? I mean, I understand why redhat has to release a new 'version' of RH now and then... to keep sales up, but...
That is SOO microsoft. We don't NEED an upgrade every year.
My problem, though, isn't with redhat releasing them.. it's with people who decide to 'upgrade' their systems. Feh!
Why do you upgrade something if it's not broke?
Rule #1 of systems management: if it's not broke, don't fix it!
I hope so. I hope that Rob and Hemos realize that there's more things going on in the world than Linux. If you disagree with me on that one, you probably live in a cave with your 2.4.01 kernel, hacked to stay semi-stable.
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
Did you file bug reports? Are you sure that your code that 2.7 accepted was good code? (gcc 2.7 and earlier accepted all kinds of crap that is not C++).
I currently work for a large blue computer company. I went to an interview at a large fibrous telecom company and was asked what distribution I am most familiar with and prefer to use. They were shocked that it was Slackware and not Redhat. This just proves what I have always suspected... the folks at Redhat are just irresponsible... and don't have pride in tier work.
I wish I could convince more people at the big blue computer company that Redhat is not the pony they should be betting on.
I saw this message posted to Red Hat's bugzilla earlier today. The first thing that went through my mind was that I would NOT cause public panic by sending this to the SlashDot admins until I had first made a tactful inquiry to Red Hat regarding the situation. The second thing was that someone else would anyway.
I'm a programmer. I'm not on the gcc lists, and I don't stay abreast on the current version or issues so the message from the steering commitee scared me. I felt let down by Red Hat. However, having read your post (particularly where it regards the FreeBSD developers), I feel somewhat relieved.
If gcc 3.0 is released during the life cycle of Red Hat 7.x, then will Red Hat be able to include compatibility libraries for c++, and otherwise upgrade to gcc 3.0 final?
I'm still hoping that Red Hat responds to developers in a reassuring manner soon. : )
What, exactly, does the gcc team mean by "binaries won't be compatible"? Will an RPM built on a RH 6.2 system run on an RH 7 one, and vice versa? How about other distributions?
I'm as happy as the next guy to see progress being made on gcc - I've spent more time than anyone should on chasing down optimizer bugs - but if it breaks things in a major way, this is a Bad Idea.
--
Disinfect the GNU General Public Virus!
What would have been the cost for redhat to wait, say for the 2.4 kernel, kde 2.0 and a stable GCC? After all they have a stable distro out, and people seem to like it. I think the problem is that the money counters and stock watchers are getting nervous ("RedHat sales aren't what they used to be *panic* SELL SELL SELL!") Thus they produce a crappy distro, it says "NEW 7.0!" on it, so people will buy it (fools)
The problem with being a publically held company in todays "new economy" is that stock market investors seem to be incredibly short sighted. Investors only care about making a buck from a move in stock prices. When CEO's and CIO's only worry about stock performance and don't look out for the long term growth of an organization then the company is in deep doo doo.
RedHat should have waited, a more stable solution would have been a better image enhancer, better for the company long term (don't have to issue so many bug fixes) Instead they chose to carry on the great tradition that every RedHat .0 distro is sub par.
"Science is about ego as much as it is about discovery and truth " - I said it, so sue me.
From what I heard, RedHat thought that the gcc 2.96 snapshot they got would be library compatable with gcc 3.0. They didn't want to ship 2.95.2 because it is a dead-end branch that isn't compatable with either 3.0 or egcs. They didn't want to ship egcs because stuff like kde2 won't compile with it. They truly stated that they *really* wanted to avoid breaking the C++ ABI twice (once going to 2.95.2 and once going to 3.0)
So, they were caught between a rock and a hard place... The didn't have any "good" compiler to ship, so they did the best they could and shipped an older egcs release as "kgcc". They could have postponed their release (like Linus just did for 2.4), but who knows how long before 3.0 is released? Also, they have a lot of customers without requirements for a specific version of the compiler... Why make those guys wait for the GCC guys to get 3.0 finished?. As it stands 2.96 compiles most C and C++ code correctly (or as well as any other version of GCC), and kgcc compiles the kernel. It Seem To Work(tm) for most people, if they have correct C++ code, and use kgcc for the kernel.
That said, there have been a *lot* of problems reported with RH7, though many come from not RTFM ("I can't compile my own kernels!"). They probably should have delayed shipment for more QA, but not necessarily waited for a new compiler.
The Alpha back end isn't great
For values of "isn't great" equal to "sucks large sharp pointy rocks soaked in cow piss". The optimizer, in particular, does quite a crappy job, and breaks if you look at it crosseyed. I never had coredumps in Hercules runing all sorts of stuff till I told gcc on Alpha to do -O3.
--
Disinfect the GNU General Public Virus!
yes.
i use redhat because it lets me get my work done. as a developer i don't have oodles of time to tweak configs and build every package from scratch. i have done it in the past - for both linux and sunos. it was fun. i used to find rattles fun too.
at the moment i'm more interested in getting my personal and work projects developed and running. that involves c, perl, php3, perl modules and i'm hoping someday to find a use for the Inline::C modules... ah...
anyway, quite the funny/snarky comment, but in relaity many people find redhat a great base for doing real development. therefore they need a good c compiler.
US Citizen living abroad? Register to vote!
Let me put it in these words: How would you like it if someone took your open source project (GCC) and decided to release a new version without your permission. I believe this is otherwise known as hijacking. This is essentially what RedHat has done like it or not. This type of action is not acceptable. Stop making excuses and fix the problem. I suggest you either release a blessed gcc from the gcc community or call what you have done something else like rgcc.
-Jet
Neat, you've demonstrated that I have more to learn. :-)
Need a Python, C++, Unix, Linux develop
C++ today is not really the same thing as it was a few years ago, and the new compilers are making that painfully clear.
Just a comment on what we're going to have to go through when GCC 3.0 comes out. No bitching allowed, since it's the natural progression forward.
--
Never hit your grandmother with a shovel, for it leaves a bad impression on her mind...
Like Joe, I have used GCC since the early days, and 2.95.2 is by far the best and most stable release.
What Red Hat should have done, was to release their own version under a different label, like they (the Cygnus part of the company) earlier have released their own GCC versions under their "GNUPro" label.
is actually a common practice. Sun for a long time shipped a separate cc that they supported only for building the kernel (this was before dynamic loaded kernel modules). I suspect most of the closed source OS companies also use older versions of the compiler.
What you have to realise is that kernel code is very low level, and often relies on features and missing optimizations that would never affact application code.
While one should of course fix the kernel (or provide hooks in the compiler) to make them work together, holding back the release of one for the sake of the other is rarely a good idea.
Clearly I see what the steering commitee is concerned about as far as compatability goes. But I have to think back to the very idea of open source. Even if this version of Red Hat Linux isn't accepted very well. The feedback it generates will be a valuable resource for Red Hat in it's future decisions. I also think the GCC developers would enjoy benifits of the feedback people give from use of this version too.
Seems to me Red Hat or any other distro who is involved in open source has choices they make concerning releasing their products. If they choose to ship a product that includes something that isn't quite "prime time" ready then that would be their decision to make. Perhaps it doesn't sit well with others, maybe it does. But in the spirit of "release early, release often" I don't see where this is a problem.
As with any "choice" there are consequences to the action. I'm confident that Linux users and Slashdot readers can make their own decisions regarding what is best suited for themselves.
I read a thread or two in this discussion where one stated "we don't need an upgrade/new release every year" or something to that effect. I agree, and since I agree I don't run out and grab the latest version of my distro of choice just because it is new!
That being said if Red Hat ships something that the Linux public doesn't like then I say tough cookies for Red Hat. However, this version of their distro is, after all, their version to release. You are not required to buy it, download it or even give it a second look if you don't want to!
Red Hat cannot be pressured by outside influences in it's shipping of a product. Just as a software developer shouldn't allow outside influences to dictate what they want to do. Red Hat didn't create GCC they are just using it. And I believe if you downloaded the version of GCC in question there are readme's and such telling of it's development stage and more than likely recommendations to its use in a production environment. ( note* I didn't conferm this as this practice is about standard in most cases with open source software )
I see this as a choice Red Hat made in their newest version. Now we all have a choice to make....accept it as Red Hat shipped or use another distro or version that suits us. Or hell, hack it to suit your needs.
Im not defending Red Hat or the Streering Committee. Im trying to point out the obvious here. If ya don't like it, don't use it! They may be the biggest game in town, but they are not the only game.
As for the Steering Committee I think they need to consider NOT posting open source software in any development stage if they are going to bitch about it later when someone acually uses it.
That is contraindicitive of the open source model of release early and release often.
Integrity is what you are when nobody is looking.
2.95.2 is armed and dangerous with optimizations on. I've seen it completely remove reverse-counting for loops with substantial bodies (ie, for (i=7; i>0; i++) { guts_of_application(); } disappeared entirely from the generated code). And this is on x86, the supposedly most stable target.
This is, of course, making the big assumption that the GCC guys would accept help from Red Hat.
Even in the open source world there are still egos and politics. And, if Red Hat simply had taken the current rev and worked on it further, you may have ended up with another compiler and not GCC 3.0.
Refrag
I have a website. It's about Macs.
Redhat has a history of doing things like this. In some earlier versions, they decided to include development versions of Perl. This really messed up everyone doing Perl support, and, of course, screwed up everyone who was using it.
"I may disagree with what you have to say, but I shall defend, to the death, your right to say it." - often attributed to Voltaire
The FSF exists to protect the right of Red Hat to do exactly what they have done. But that doesn't mean they (or the Steering Committe, which are managing GCC on behalf of the FSF) have to agree with it. There is an important difference between saying "I forbid you to do that" and saying "You are allowed to do that, but I believe you should not do it anyway, and here is why..."
Next time, try reading that file before shouting "it isn't documented anywhere" on Slashdot and in Red Hat Bugzilla.
GNU/Linux. The Freshmaker.
They are talking about the automagical update daemon service. Redhat requires you to pay for a subscription.
You can't have a stable ABI when the language itself is still evolving. GCC 3.0 will be the first GCC version implementing the final C++ standard (including the standard library), and it will be the first GCC versions to promise a stable ABI.
My "deluxe edition" subscription to the priority ftp site for errata just expired, so they had already planned this release date for the next rev. Despite the perceived audience, "release early and release often" still applies to an entity such as RH.
Mandrake 6.1 was shipped with broken compiler but not the 7.0 we used the official version of gcc2.95.
The trouble is that this may not make RedHat's life any more difficult, it certainly makes the job of anybody trying to ship "Linux binaries" (well, for C++ only, but the point still remains) considerably more difficult, and could conceivably encourage "Red Hat only" products to be shipped, which is the kind of stunt that we get annoyed with closed-source companies pulling. I'm not saying that this was their goal (in fact, I'm sure it wasn't), only that if they were trying to pull such a trick shipping a compiler generating non-standard binaries is one way go to about things.
Secondly, and more importantly, people are still going to complain to the gcc mailing lists about bugs in the gcc shipped with RedHat, when it's not a release that the gcc developers were prepared to stand behind, and the gcc developers will probably go nuts generating the same replies to the same problems that weren't in the stable release, aren't in the current development tree, but were in the particular snapshot that RedHat decided to use. While they might want to say "rack off and complain to RedHat" they almost certainly won't because they care about users and the good name of their product (even if it's not really theirs).
In essence, RedHat has to realize (and they probably do) that their actions affect the whole community, and their continued good name depends on them acting responsibly. Look, there may well have been compelling reasons for shipping the non-standard compiler, I'm not really qualified to comment. However, it's not an action they should have taken lightly, and it seems like they could have handled relations with the gcc developers better.
Any sufficiently advanced technology is indistinguishable from a rigged demo
--Andy Finkel (J. Klass?)
As one of those "rare people" who have the technical knowledge to understand a broad range of computer/information-related ideas/tasks/problems/solutions, and who also has some good managerial/political skills, I'd like to say that I agree with you in principle.
However, it's as easy as you make it seem. I've learned quite a few things, and one of them is that most people participate in active stereotyping to some degree or another. In my experience, the more of a "fringe" group you are(translated: the more specialized your proffesion or way of life), the more you stereotype other people. I've suffered from this myself, and at least for me it stemmed from the fact that most people quickly and effortlessly put me into a stereotype, often with confidence-shattering results.
What I'm trying to say is that a lot of managerial-types I've dealt with need things explained to them not only in terms they understand, but also from someone who they think is a member of their own stereotype.
On the other hand, most techies I've dealt with also need things explained to them in terms they understand(and, well, let's be honest - everyone needs that for the most part), but they also need to hear it from someone they feel is a member of their particular stereotype.
This is a very difficult thing to accomplish. In one particular job, I did fairly well. I'm a pretty good actor, and had two different personalities/vocabularies/mannerism-sets to use with the two different groups of people. I thought it would be a great idea if everyone got together to hammer out some issues, and everything fell apart.
The managerial types saw that I related well with the techies, and they immediately got their hackles up. (after talking to a few of them, they said they had felt betrayed - I had put them on. In reality, that's exactly what I did, because it was what I needed to do to get the job done) The techies say the way I talked with the managerial staff and felt that I was really sort of a "spy". Someone who was actually management, trying to horn in on them. Fact is, both groups had taken my suggestions well, and we had implemented what we could. Compromises were quickly and easily reached, but as soon as everyone saw that I wasn't part of their stereotype, they didn't trust me. I really don't think there's much that can be done about it. You NEED to be able to talk to people in a way they'll understand. And, if you honestly sympathise with them, you shouldn't hide it. In this particular case, I was pretty much screwed. Luckily the project was finished and I was able to move on, but I'll never put myself in that situation again.
Dave
'Round the firewall,
Out the modem,
Through the router,
Down the wire,
Barclay family motto:
Aut agere aut mori.
(Either action or death.)
It works fine, with a few caveats (e.g., std::stringstream). You can alway use STLPort or libstdc++v3 anyway.
Also, that C code is probably broken code that gcc 2.7.x just happend to accept.
Just about anything is better than aCC (in terms of adherance to the C++ standard, at least)
Last I checked, GCC (2.95.2, I think) still had some problems with pointers to virtual member functions, but it does warn you, and that is one of the more obscure and poorly implemented features of C++.
Actually, I suspect that it was testing that convinced them to go with 2.96 rather than a more offical 2.95 release.
There would be incompatibility with the forthcoming (but when?) version 3.0 anyway, and 2.95 blows (though many problems from 2.7 are at least partially solved).
The problem with the strategy which RedHat has embarked upon is that RedHat has always committed to keeping full binary compatibility during a particular major release series. So there was full binary compatibility between 5.0, 5.1, and 5.2, and between 6.0, 6.1, 6.2.
By prematurely going to a pre-release "GCC 2.96" which will not compatible with the eventual GCC 3.0, it will force Red Hat to continue to maintain the same random development snapshot through the entire 7.x series --- which if past history is any guide, might be a year or two, even if GCC 3.0 by some miracle ships in a few months.
Worse yet, it puts the other distributions in one heck of an interesting dilemma. Do they follow RedHat and use the same non-GCC supported compiler? Or do they use GCC 2.95, and then be incompatible with binaries compiled for RedHat 7.0 that happen to use C++ and shared libraries?
As we have seen in the past, the Red Hat marketroids have tried very hard to pursuade ISV's to make binaries available for Red Hat, and they've tried very hard to get the rest of the industry to believe that Red Hat === Linux. I can't necessarily fault them for that; they have a fiduciary responsibility to their shareholders, and such microsoft-like tactics are the best way to build the RedHat brand. After all, at the recent open-source conference, Michael Tiemann boasted, "The Linux distribution game is over. Red Hat has won that game. Red Hat is the market leader in virtually every respect." (I suppose this ignores SuSe in Europe, or TurboLinux in Asia, but whatever.)
So ultimately, having them choose something with a non-standard ABI that's not going to be supported by the Open Source project, even if it is only for C++, is quite troubling.
That was a internal misunderstanding since resolved - they could have told the steering committee, but preferred to be cautious.
Anyway, with what was shipped in the public beta two months ago I can't understand why the release surprised anybody. Going back from KDE2 because it was just too buggy is one thing (it's included as a preview, though), but changing one of the major subsystems like glibc or the compiler after that was obviously not going to happen.
Just so you know, Visual C++ isn't anymore compliant than g++. Actually, VC++ has had horrible template support. Perhaps the latest versions are better, but sticking with VC++ does not guarantee a better compiler/more ANSI compliant.
NOTE: This isn't a MS slam. It's just a fact. Micrsoft would much rather you work with their ATL, because it is "better". I don't know why, but apparently it just is. So MS is just as non-compliant as g++ (the last time I checked). Your text books might take this into account--so they are more VC++ compliant than they are ANSI C++ compliant
Also take a look at g++. Its support is increasing--faster than most commercial vendors. It's a great compiler. We are all just experiencing the growing pains.
"Doubt your doubts and believe your beliefs." -- Switchfoot, Ode to Chin
For your information Cygnus called it egcs and not gcc. Because of this, everyone knew it was a code fork. Egcs was the right way to do it. Eventually it did become gcc but that is another story. Now what RedHat has done is a code fork and called it GCC 2.96. This is just plain wrong. So please enlighten me why I should see it any other way.
In the college world c++ is the DEFACTO STANDARD AND NOT C.
I'm a CMU CS student, and I can tell your for a fact, it most definitely is not. 95% of all coding is C (the resting being a mishmosh of C++, Java, and ML).
--------------------------
Troll alert... Bzzt. Wrong. Trumpet Winsock was written completely from scratch to have a clean copyright from the very beginning, and I can tell you it was no easy task to code TCP directly from the RFC's despite the occasional peek at existing code. Another reason I didn't borrow any code was simply because there was none - my first application was in Pascal (Trumpet Newsreader), and at the time no Pascal tcp stack was publicly available anywhere. It was only with the support of my wife who believed in what I was capable of that I even embarked on writing a TCP stack from scratch, and the rest is now history - all those computer widows take note.
:)
This was done at a time when just most of the commercial stacks were derived from the BSD Net2 code. And I even remember at the time that I got involved in the Internet that there was a rumor that MS felt that the Internet would not amount to much. They changed their tune within a couple of years though
Finally, my beef is not with MS. We were fully aware of the risks and the direction that MS were going when the company formed. I keep a respectable distance from them, and presumably they respect us also. My beef is with the myriads of unscrupulous companies who thought it was fair game to simply use and distribute our product without any hint of royalties being paid by themselves or the end users. I think that in itself speaks about the quality of our product and why it may have been an important step in bringing the internet to many desktops even though the lost revenue to ourselves runs up into the millions.
I have first hand experience of widespread exploitation of software, and that's more about what I am referring to mainly. With this issue I am seeing some worrying influences of corporatism taking seed and it would be good to understand the full implications of what has happened. To me it's a classic question of who's really in control.
what can I say.. I'm doing the EXACT same thing. Redhat has frustrated me way too much to deal with them anymore, and this gcc stuff is the end of it. Anyone know where I can get debian iso's at (I crawled around in ftps for like 20 minutes and still can't find anything.) -neil
"Now you see that evil will always triumph because good is dumb."
Kai C++'s sales brochures say the export keyword is supported. Don't know for a fact, though, since I've never used Kai C++. Seriously considering buying a copy, though, if it supports templates any better than egcs does.
Let's not even get into the STL implementation in egcs. When I can't use at() on an STL vector, I get deeply annoyed. Admittedly, it's a trivial thing to fix, but there are things like that all over in egcs--things which ought to be fixed, things which are trivial to fix, but which, for reasons unknown to me, aren't fixed.
Personally, on this issue, I think that Red Hat is going to end up eating crow. They released a piece of software in their 7.0 release that isn't just unstable, its necessarily incompatible with any other release that they have to date, and any future release that uses gcc 3.0. It's no different than if they decided to fork the gcc code, and from now on they either have to support that fork all by themselves or go back to the non-forked code.
It also means two other things. First, Red Hat 7.0 is a release to avoid because it guarantees incompatibility. But we already knew that. Every Red Hat x.0 release is a release to avoid. Second Red Hat now has to tell their users who upgrade either to 7.0 or from 7.0 that they're going to lose binary compatibility with previously compiled code, and possibly with future compiled code (assuming that Red Hat will eventually go back to gcc 3.0).
The least we can say about this is that it will have created extra work and bad PR for Red Hat. The most it seems we can say is that it was a major gaff. But to talk about Red Hat as if they're sneaking around and abusing gcc seems a bit much to me. It's GPL'ed software, and as such its use is free (as in speech) to whoever downloads it.
I always thought that someone using GPL'ed software outside of the manner intended by the auther was an explicit feature of the GPL. To complain about someone actually doing that seems more like the tactics of the software proprietors.
I'm sure that I must be missing something. Can someone help me out?
Key to financial independence: Spend less than you earn. Save and invest the difference. Do it for a long time.
I have rigid deadlines that have to be met, so it does look like Q4 2000-Q1 2001 will be the release date - hope I don't burst my boiler doing so :)
The first target (fully functional kernel capable of providing base win32 kernel services) has been reached without blowing out by more than 3 months. The next target is a GUI which could effectively run a thin client or bare bones windows apps - this is about 30% done and I hope to achieve this by the end of the year. The graphics framework is running, and all I need to do is build the widgits and glue code to interface to applications and we're pretty much there.
I'm from Canada(Waterloo), eh? and we use modula-3.
I don't know what planet you live on. I use (used to use!) RedHat RPMs on my Slackware boxes regularly without a problem.
Be careful. People in masks cannot be trusted.
Yep, all of a sudden, its "cool" to be using Debian, and "cool" to bash RedHat...
Oh well, as with all things, there is a time and a season, and people like to pull down whoever is on top. I don't see anyone yelling at Mandrake for not having all the SRPMS for their packages on their ftp site, or see them yelling at SUSE for not having the installation ISOs available right away after they have a release, or at Slackware for version number padding just to look like they are a modern distro. But like i said before... its the order of things.
I still like RedHat, and i still use RedHat...
You guys always have SRPMS for your packages, always get the ISOs out right away, and The source for the installer is available (even though i thought it wasn't cause there wasn't a misc directory in 7.0, but then i saw the anaconda package)
So, everyone seems to hate RedHat, just remember that I don't, whatever that might be worth.
Its spelt "L-I-N-U-X", but pronunced as "Free Beer"
No, they don't *make* you pay for a subscription. You have the *option* of getting one, but you can do the automagic updates without the thing. All the subscription gets you is gauranteed priority access... the benefit of NEVER seeing "Anonymous user limit reached"... etc. Not very worth it to most of us, but perhaps to some. The only way that I see that differing from Debian, is that debian only gives you the non-subscription option... which doesn't matter to me in the least, but I don't see why RH would be condemed for giving that option.
The company can release the distro to satisfy the demands of the customer base to provide timely updates of software. So, they take what they consider the best of what's available and release it after what must be an un-Godly amount of work. So, upgrade if you want. Wait for 7.x if you want. In fact, with the info I've gleaned here, because the compatibility of binary code is touted as being manditory, Redhat has the opportunity to release a 8.0 when KDE, XF86, and the gcc compiler group have things that are ready for the public consumption that they claim they desire.
- real hackers don't have sigs -
You're probably confused (likely an understatement) with the $19.95 service of getting update CDs shipped to your door monthly.
--
The unsig!
Red hat is famous for pushing new tech into the limelight...If not for red hat, we'd all be a few versions back.
would that necessarily be a bad thing? i've been following Red Hat since 4.2 through their little song and dance (first we release a completely broken *.0, then we release a *.1 that fixes some things but breaks many others, and then we finally release a *.2 that works kinda ok).
i don't think Red Hat should be responsible for jamming the latest and greatest untested tech down everyone's throats. people who want the bleeding edge can go get it themselves - personally, what i'm looking for in a distro is stability and functionality. let somebody else test the innovations, and when most of the kinks are worked out, then i'll use them. i can wait until then.
-steve
--- "We also were guided by the unlikelihood that anyone would face supernatural evil armed only with technology."
Actually, there's an easier way to compile a kernel with kgcc (at least when I built 2.4.0-test8):
In linux/Makefile, there's a variable called HOSTCC. Just set it to kgcc, and it should be all good.
The most popular language (in terms of number of programmers) is VB
The most popular language (in terms of active lines of code still in use) is cobol
The most popular language (in terms of useful lines of code still in use) is C
The most popular language (in terms of useful lines of code being written) is probably C++
The most popular language (in terms of brand new projects) is Java
http://rareformnewmedia.com/
it will force Red Hat to continue to maintain the same random development snapshot through the entire 7.x series
:-)
What 7.x series? The new release is Redhat 7, which suggests the next release will be RedHat 8, sidestepping the problem entirely.
1/2
"It's overkill, of course. But you can never have too much overkill." - Anonymous Slashdot Coward
Yep! All the time.
rpm -ivh something.src.rpm
hack hack hack the specfile
rpm -ba something.spec
Whee! Just like tarballs, but with sprinkles!
-- Post No Gravy
Stop and think. Why would a distribution ship a compiler that is off the development branch? Why in God's name would they ever do anything so incredibly horrible as that?
Simple: features. Many of you may be C programmers, so you may be scratching your head right now, saying "Huh? What features?" But if you work with C++ (and you will notice it mentioned specifically in the post from the GCC team), you know what features RedHat was trying to get by going with the supposed "2.96".
Now, before someone goes off all half-cocked and starts bitching about C++ and C being better, go read up on Inti, specifically on the why's. RedHat will make its money either directly or indirectly from its distribution--the more people who buy Linux, the more ways for them to make money. More people will use Linux if there is software. More software will "appear" if companies use Linux as a development platform.
From what I have read about Inti and its reasons for being started, companies are passing on Linux because they cannot get good enough C++ support and tools in Linux. That's right--C++ support is hurting Linux.
Yes, yes--C++ sucks, yadda, yadda, yadda. Stop and think. The reason so many of you turn your noses up at companies and work is because they pretty much require you to use C++ anymore. I'm not saying it is fair. I'm not saying it is necessarily a "good thing". I'm just raising the issue--most development shops, if given a choice between C and C++ use C++. Perhaps this is all Microsoft's fault. I have no idea.
But I happen to use C++. And let me tell you, writing C++ with the gcc/g++ is a royal pain in the ass. The ANSI standard has been out, and many vendors are still getting their stuff together. But the gcc is one of the lagging ones (IMO--I may be wrong, please list any worse offenders). You buy the C++ Reference by Stroustrap and try to follow the examples (try using sstream with anyone besides RH 7.0, and you will see what I mean)--endless amounts of frustration.
RedHat is just sooooo evil. They included a compiler that had better C++ support. Before you demonize them, stop and try and see it from their perspective. I for one, appreciate a better STL implementation--the one in 6.2 was just aweful. 6.2 had a C++ library with a build date of February 2000. Now that may *sound* new, but it isn't. It isn't even close to the current standard in some areas.
All that being said, I'm not sure that the "negatives" that come with 2.96 were worth it. I would have rather seen RedHat include a good STL port (I hear there are a few good projects out there). Still, the C++ support found in current Linux distribution sucks. Just join any linux C++ project mailing list and see how many times gcc bugs will come up :-(
And if you think this is flamebait, you best check your moderator rules.
"Doubt your doubts and believe your beliefs." -- Switchfoot, Ode to Chin
parent is false - just check http://gcc.gnu.org/steering.html and you'll see that both of these people are still listed on the committee
The Matrix is going down for reboot now! Stopping reality: OK. The system is halted.
Red hat is famous for pushing new tech into the limelight. First with glibc, first with kernel 2.2.x, first with ipchains, and now first with xfree86 4, first with 2.4.0. If not for red hat, we'd all be a few versions back.
I also work for a large blue computer company. When I joined one of the Linux teams, I was told I wasn't allowed to use Slackware on customer machines. This was due to 'no vendor/support strategy'. Same with *BSD. However, I'll continue to use Slackware everywhere else, since I haven't seen a bad Slackware release yet.
For those of you who think I'm bashing Redhat, take a seat. I'm also an RHCE, and I've used RedHat for years as well.
Given that we want a good multiplatform compiler, we didn't have much choice.
As for incompatible, the C ABI works and C++ has never been binary compatible and AFAIR, the drafts I've seen of different compatibility standards mentions this explicitly: Avoid the horrible mess that is C++ if you want binary level compatibility.
Shut up, fool.
Bleeding Edge Technology held as number one suspect. GCC Steering Committee denies all responsibility! More to follow!!
Wohhoo... things are getting interesting again on slashdot after a bit of a slow summer!!!
Non-Deterministic Finite Automata
Too bad the troll didn't really deserve them...here's where I take you to task. Now listen up; you'll learn something.
/*
Just another example of market pressure to disingtuish one distribution from another.
*/
OK, on 2nd thought, I won't. That's just dumb.
/*
Show me the GCC Steering Committee Linux, and I'll bite.
Funny that there should be more releases per
distribution than actual improvements to Linux, per se. Its basically the same Linux for almost 2 years running for all I can see.
*/
FUD! Yippee!! Red Hat Linux != Linux. Linux is a kernel; (Linux || GNU/Linux) is a Linux kernel with GNU utils (which strangely end up migrating to BSD machines; hmmmmmmm.....) and other miscellanious(sp) crap. I won't even touch the last sentence since it makes 0% sense to me. Rubber doggies eat yellow daisies.
/*
I like the way the steering committee refers to it as Gnu/Linux. If you cant even decide on what to call it, what are the chances that
you are going to agree on timely communication and a sane development model? You know, cvs and all that rot. Currently you have
LinusOS + GNU + Di$tribution du jour + a legion of cheerleaders.
I'll stick to FreeBSD.
*/
BWAHAHAHA!!!! That is so *incredibly* funny. I *know* you can't be serious now. FreeBSD (IIRC) source is updated preferably through cvsup. As far as Linux vs GNU/Linux goes, who cares other than RMS & the Stallmanites. I use both interchangably; hell, Linus doesn't even care how you *pronounce Linux.*
As far as the FreeBSD comment goes...yeah, like FreeBSD is 100% identical to other BSDs. BSD=BSD kernel + BSD utils (maybe...AFAIK lots of BSDers switch to GNU pretty quick, or so I've been told by many a BSDer) + Distribution + a legion of the cheerleaders from Nirvana's "Nevermind" video. OpenBSD, FreeBSD, NetBSD, Darwin, MacOS X...the list goes on and on.
Stating on Slashdot that I like cheese since 1997.
You all keep posting your derisive comments about Red Hat's latest release, 7.0. Our Friend, Bero. Let me tell you a little story about this "Bleeding Edge, Broken Release," as you like to call it...
Bero was walking down the street in some hick town in Oklahoma. It was a brisk Autumn day and Bero was shivering in his jean jacket as he contemplated his lot.
"Why don't people like me? Why am I so unpopular with those cool guys on Slashdot?"
As Bero walked, lost in his thoughts, a tall, thin man approached. The man had a face that was badly scarred by acne and a long, black moustache that glistened with natural oils. The man stumbled into Bero.
"Oh, I'm terribly sorry," the man said as he lifted Bero from the sidewalk, "I didn't see you coming!"
"It's ok," Bero said, on the verge of tears, "I didn't see you coming either."
The man brushed the dust and horse manure off of Bero and looked at his sullen face, "my god! You, sir, are a star waiting to be born! You must come with me to Hollywood, where I will launch you on a stellar acting career and land you guest appearances on Oprah!"
Bero was shocked, "yes."
Bero went to Hollywood with Mr. Garcia, who had just quit the used car business to become a big-city talent scout. Using elicit substances, he landed Bero a roll in the Upcoming "Star Wars: Episode II" movie.
Bero auditioned many times before landing the role, pulling up his deepest feelings of rejection, which had been heaped upon him on Slashdot. Finally, Bero's life was about to change.
Bero sat in his chair, which displayed his name with a single star above it. He watched the crew prepare for the next shot, in which Bero was to portray a Mexican fetal sloth. He noticed a nubile figure approaching from the fake mist...
Bero did not recognize the pouting teen breasts and firm teen buttocks that bounced his way. The long, flowing, silken hair stirred no hormonal reaction. Natalie approached Bero, smiling coyly.
"Hello, Bero. My name is Natalie. I am hot and young and an actress!"
"Hello, Natalie. I am Bero. I am a lowly point-oh release. I will be replaced with superior products. I am broken and unstable."
Natalie put her tender hand tenderly on Bero's tender chest, "You are like a cottonwood seed, caught by the March winds and blown into my back yard, where you land on my face and tickle my cute teen nose!"
Bero's heart melted. He, at last, knew bliss!
"Let us run away together, Bero! Let us forget the bright lights and plastic faces of Hollywood! Let us forget the wandering sheep of Slashdot! Let us merge together and make our own point release!"
Bero leapt from his chair and clung to Natalie's neck. They laughed heartily as the walked off the set.
Bero and Natalie sat on the beach of Cancoon, absorbing the life-giving rays of sunshine. Natalie caressed Bero's shock of hair, "I have a 4 gigabyte SCSI (pronounced 'sexy') drive I'd like to install YOU on!"
i like german girls. and nannies.
So does this mean that the next major version of GCC will break everything with C++?
Sourcecode compiled with the compiler shipped with Red Hat Linux 7.0 should still compile - binary compatibility will also be preserved through the 7.x series. As for other binary compatibility with C++ (i.e. outside of Red Hat Linux), probably not - which is no change from the current situation.
Is there an "offical" stable compiler included?
This sig intentionally left blank.
Binary compatability with other distributions is much less important. You can't install a .deb on RH, you can't really install a SuSE .rpm, and these days you push your luck with a mdk rpm anyway.
It isn't really that hard to recompile OSS code for a different distribution, anyway. Comercial software companies, I guess are SOL until most distributions have a gcc 3.0 blessed set of libraries, so they will probably have to statically link against libstdc++ if they want portability.
RH does ship compatabilitiy libraries whenever a new release breaks binary compatability, though I don't know if they tricks they play will help out a binary compiled on a different distribution.
That (and I say this with respect Ted) is such a crock. We are talking c++, and it's at&t's fault for not bring an ABI for C++, not redhat.
/.
Is your theory, that marketing called up alan, asked for a piece of linux that's neither binary forward nor binary backwards compatible. He says, C++ of course?
That's so lame, the real problem is c++ is crap until they get a standard ABI.
Now, I'm not certain, but couldn't redhat push out the new c++ library on top of redhat 7.x (when it comes out) so that other vendors don't have to ship the redhat version? Maybe not, but I don't care anyway.
I'm sick of this va/andover anti redhat crap. This used to be a community, now it's a damn warzone, and it's spreading beyond the *.advocacy/*.shadow-conspiracy places. If it had a bit of truth, don't you think we would know?
What the steering commitee did was right, but the theories are worthless.
Please Malda, end the fscking troll/flame stories, and save
Thanks.
In my opinion, Open source is going to show more and more of these problems because of the conflict of interest between open development and maintaining commercial advantage to remain competitive.
The fundamental issue is that if you are going market an operating system, you need to have a well defined and controlled environment for building the OS, especially the compilers and linkers. In fact, the very first part of the PetrOS project was to create a compiler capable of building the kernel from, which has proved fruitful because the kernel is extremely stable - I know exactly what machine codes are executing at any point in the kernel. When you are left to a 3rd party compiler, you are at the mercy of the compiler developers interpretation of how the language should be implemented, and even suffer the bugs they may have left in the distribution. I am only too familiar with that aspect.
The other issue that open source developers face is the frequent version releases, some perhaps not fit for public consumption. Clearly in this case, the gcc people should have made their version numbering scheme represent the beta nature of the product. Heck, even we do that with Trumpet Winsock. Before we go to major version release, we tag the version number with a beta sub version number to clearly indicate that the product won't be supported and that it should not be used for any production implementations or distributions.
It is for precisely these reasons that I have opted not to endorse an open source model for the PetrOS project, but rather some form of synthesis whereby key parts of the distribution are kept closed source, but allowing some of the outer edges of the project to be open source. I believe this is the only way for complicated projects like an operating system.
The other comments I hear (hearsay???) about Red Hat being closed shop about their plans hints of corporatism.
A word of advice to all those penguins out there. Beware the corporate world - it's ruthless and they'll take every advantage of the open source movement, even to it's detriment!!! I'm certainly not saying that Red Hat are doing this, but sooner or later, some company who wants to cash in on the Open Source movement will come in and plunder all the good work that's been done. Perhaps this incident is a small warning of what *could* happen. It's happened before in other parts of society - eventually "feel good" movements get exploited in one way or another either politically or economically.
I could say more, but it really deserves a much better appraisal than an off the cuff comment on a forum.
Don't get me wrong, I am in no way denigrating Open Source - I'm just saying that trying to operate it on a commercial basis is full of problems.
Hrm... come on, 2.95.2 isn't that bad, i run LFS (LinuxFromScratch, http://www.linuxfromscratch.org) and have had _no_ problem compiling anything (this includes several servers/desktops/laptops) nor running, so..?
Dunno, i don't agree with using snapshot's in distrobution... i find that just wrong, imho
-
gcc 2.96 generates binary incompatible C code.
It is clearly marked as a snapshot(the version string says "Red Hat Linux 7.0"), and it is currently the best compiler for our needs.
We're obviouly not going to issue a "blessed" errata unless it is fully compatible - we care about our product and and compatibility, having multiple releases of compilers etc. is completely unmaintainable and might confuse people developing on it.
Anyway, this discussion is at a dead end. We released a fixed snapshot, we're not doing anything wrong with this (we should have told the gcc steering committee, but technically it was the right decision) and we're not going to break compatibility with it. EOD.
Right on. I'm still using Pinstripe beta (so shoot me), but the most I've noticed is that Blackbox wouldn't compile until I fixed some bad code of theirs. Other than that, 2.9.6 works absolutely great!
Just a few random quotes and comment by an experienced developer.
:-)
> I consider myself a fairly jr level programmer so I probabbly still need to learn the differences between c and c++ allittle more.
So you admit you are not qualified for the issue, but ask the orginal post to be modded up, and title yours a 'someone see s the light'. Pretty logical to me.
> I do not understand why c++ is shunned by so many c programmers. The arguements I hear are performance related gripes by old timers from the unix mainframe world of the 80's.
Speed argument don't hold and never had. The arguments against C++ are basically:
* C++ is complex
Complex -> difficult to master -> most people don't -> more crappy code.
I consider that it takes 12 months full-time to a good developer to master C++ (up to the point he'll be pretty sure of all the issues involved, from throws clauses, auto_ptr, const methods, etc, and all the interaction between them). That's a *long* time.
* C++ use several paradigm at once
This gives trouble when mixing/matching libraries from different sources. Template base code + Heavy inheritance based code = big headaches.
* C++ enforce no paradigm/policy
Even for a experienced programmer, code written by a different developer is alien. One that code with abstract base classes and a nice hierachy of object for several years will not even be able to understand nice STL based code.
* C++ is not Object Oriented.
It lacks dynamicity, which is a real problem for some projects. Unfortunately it is not stated upfront, so generally the mess appear in the middle of the implementation phase.
* C++ is a fragile language.
Add a virtual method in a header and you have invalided all the binaries that depend on this class or one of its subclasses. Even worse if the header is a template.
Loading new classes at run-time is nearly impossible in C++.
* C++ have a lot of dark corners to be aware of
It is easy to hit the wall-of-brick (ie: something that plainly doesn't work. This using inheritance and ref counting smart pointer. It almost work. Many things "almost work" in C++) at a very late stage in C++ development. At this point, workaround starts to be ugly, and resulting code often break on different compilers
* C++ have no taste. (this is a personal one)
> I understand that I could abbusie templates and create too many objects that could slow everything down
First you mess objects and classes. Not a good point. Template based code make the compiler emit a lot of classes. Template base coded often have less run-time instances than other (ie: no need for ping-pong between classes, as code is statically generated)
> I like c++ and the uml way of doing things because it makes my code easy to read for others
This tell everything. You never saw industrial grade C++ code. Have fun in college, but beware.
Cheers,
--fred
It'll be out when it's ready.
--
I ate something that disagreed with me. Maybe I should have cooked him first.
Maybe they will go the Microsoft route, and have 1 box to sell for the whole 7.x series. For 7.1, you would have to download a 'service pack' or buy a 7 --> 7.1 upgrade cd. This is better for retailers, as then they can just sell '7' instead of having to throw away '7.0' cds when '7.1' comes out.
****Gfx Scrollbar Special case hit!!*****
Non-biased does not mean "prefer Red Hat", but it would mean not making comments like "recovering from Red Hat Linux 7" on many stories, and if someone submits story which seems negative, actually do some checking (of course, this should be done nonetheless, but it doesn't seem to)
The sites I feel most interesting these days are LWN and Linux Today
As for speaking to the rest of the authors, this was a miscommunication internally (I would estimate that most come from Red Hat anyway, from Jakub Jelinek in OS Engineering and former Cygnus)
"shipping a snapshot": This was cut of the tree a long time before shipping and then QAed and fixed. Us wantin to ship it got it huge amounts of testing and bugfixing, which would accelerate release of GCC 3.0.
As for KDE2, I just stated that preannouncing features of a release is bad in case it turns out not to be released when planned (2.4 kernel, KDE2 and others)
I don't really care too much about the binary incompatibility problem. It's a pain for libraries, but there are not yet a lot of widely used C++ libraries that I know of.
I do care very much about my compiler breaking. I have a C++ project I've been working on for a long time, and I remember the bad old days of the 2.6.x series. *shudder* I was having to #ifdef all over to make code that closely followed what then passed for the standards. And I even purposely avoided some of the newer features like templates and exceptions.
It's very painful to work around compiler breaks. Especially when you code like I do and the vast majority of your code is so cross-platform that you don't even need #ifdefs to get it to work for NT.
Need a Python, C++, Unix, Linux develop
Kernel development aren't the people doing the distribution - OS Engineering is. The kernel is only one (but major) part of the system,
Backing out major items liks glibc and the compiler late would be very hard after making the entire distribution on it (and if late enough, not enough testing either). Also, integrating these for all platforms (including IA64) would be next to impossible - the current IA64 toolchain look a lot like the one in Red Hat Linux 7, and this isn't a coincidence. Add to that that we commit to binary compatibility for many releases, and needed better i18n support for the Japanese product. We would definitely prefer not to ship pre-releases (although heavily QAed and fixed), but we felt we didn't have much choice.
Nice long post about the evils of managers, but according to http://www.uwsg.indiana.edu/hypermail/linux/kernel /0010.0/0069.html , using the GCC snapshot was a technical decision:
Richard Henderson -- You would be wrong then. Management asked what version of gcc would be best to support, we answered, they followed our recomendation.
--
Business. Numbers. Money. People. Computer World.
You just don't get it. You can not defend the actions your company has taken. You NEVER EVER release a snapshot of GCC. This is fundamentally the most important piece of the whole system. Also, it is quite apparent if you (RedHat) want to do the right thing you will release an update to replace the current GCC for RH7 with a version of GCC that is blessed by the GCC community as a valid version. I hope you (RedHat) realize that the longer you wait before fixing this issue the more your user base will lose respect for your product. Come on RedHat do the right thing. I feel an imbalance in the force...no that was redhat not thinking...
And where in the GPL does it say that we can't bitch about RH's actions?
RH has put themselves up as the public mouthpiece of Linux, and to a great extent, it has worked. Most non-geeks who even know of the existance think that Red Hat is linux. Hell, I have a (admitedly age'd) Professor that constantly says things to me about "Linux 6.2", in reference to RH6.2.
As a result of the view that the public has of Red Hat, it is in the Linux community's best interests to make sure that Red Hat doesn't seriously fuck things up. Surely, everyone around here knows that if you want a stable system, you shouldn't ever run a x.0 release of any software. Unfortunately, the public at large will assume that a larger number means a newer, more stable release.
Keep in mind that 'you only get one chance to make a first impression'. When J-Random Luser, who knows of Linux because he's heard about it from somebody he works with, or has seen an article in some glossy computer magazine about it, decides to try Linux for the first time, goes down to the local CompUSA, and drops his $30 on the big, glossy, New, Improved, Red Hat Linux 7.0 since it's obviously better than the copy of 6.2 right next to it on the shelf, and installs it, only to unknowingly run software of questionable stability, and decide that Microsoft was right, and Linux is unstable, unreliable, and full of bugs, it contributes to the negative image of Linux as a whole. </runon>
How is this going to affect the portrayal of Linux in the mainstream computer media? Poorly, at best. Taking things to the point of absurdity, something like this has the potential to undo all the work we, as a community, have done to gain mass-acceptance (or at least acknowledgement) of Linux. This could blow up on the scale of the Pentium FDIV bug, or the MSFT ILoveYou thing, but without the big-money PR departments to spin doctor it, and the massive installed base who's locked into the technology.
my sig's at the bottom of the page.
I expect this to change in the next 5 years. C++ is starting to be stable and well understood enough that compiler vendors can start standardizing on calling conventions and such.
But, it will still have the 'fragile base class' problem. That one's pretty hard to fix. *sigh* *think*
Need a Python, C++, Unix, Linux develop
Hear here! This has been my experience with gcc-2.95.2. I think its optimization could be better, and it would be nice to have support for the K6 and K7, but other than that, it's been very stable and reliable for me. I do a _lot_ of C++ coding.
Need a Python, C++, Unix, Linux develop
that is what I want to know. because if it supported cue cat it could be used to overthrow slobodan milosevic. thank you.
This is a great demonstration of the dark side of capitalism (yes, there is one, all you silly Americans).
Many think capitalism means "the customer is king". They are right -- and RedHat's "customer" is their shareholders.
RedHat has an obligation to increase their market share. In this case, they needed to ship, as rapidly as possible, a standards compliant C++ compiler.
The fact that many peons^h^h^h^h^h end users were inconvenienced is of little consequence. As an American Corporation, they actually did the right thing, if you are a fan of the capitalist method.
Corporate investors demand maximal return on their money, and RedHat must place that goal ahead of all other considerations (product quality, database integrity, etc) while they attempt to gain market share and profits in excess of their competitors.
Treatment, not tyranny. End the drug war and free our American POWs.
See my user info for links.
Do Red Hat users every actually compile anything anyway?
(boy is this going to ruin my karma)
:wq
I wonder if anybody has read the following, yet?
http://lwn.net/2000/1005/a/rh-tools.php 3
This explains the whole story - looks like the left hand of the GCC crew doesn't always know what the right hand is doing.
Anybody who's been following LWN will have been aware of this for several days now.
It seems to me that RH had to make an ugly compromise, and just bit the bullet.
-- Post No Gravy
As far as compatibility goes, glibc is the great challenge and C++ not that important: When binary compatibity is a high priority goal, C++ has never been an option when developing for Linux.
I recently upgraded to 7.0 from 6.2. What a disaster. I spent a weekend patching it, and then finally backed up my data in reinstalled 7.0 from scratch. I was then greeted by a total inability to compile 2.2.17 with the gcc in RH 7 (2.96). I submitted a bug report ("compiler screwed in 7.0") and was told that it's not a bug, that I should use kgcc to compile kernels. Of course, this wasn't documented anywhere, and in spite of the fact that I chose "kernel development" in the installer, it did not install kgcc. I had to go get the CDs and install it. When I ran kgcc -v, i saw that it was gcc (egcs) 2.91.66, which is a working compiler. So i symlinked cc and gcc to kgcc and everything seems to be fine. I asked on the same bug why they ship a broken compiler and require manual isntallation of a working one in RH7. I was told that it's the kernel's fault, read the LKML. I think my question is still valid -- why did they ship with a broken compiler? Granted, the kernel has special facilities in their makefiles for using kgcc rather than gcc, but that doesn't solve the problem for kernel modules compiled outside the kernel tree. And I still had to hand-edit the source for the Universal Tun Driver to get it to compile right on RH7, even using "kgcc".
What's the big advantage of 2.96? I haven't seen it yet, so if someone could please explain it to me...
________________________________________
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
excellent job on getting that troll modded up! go go gadget modbots!
Dunno, i don't agree with using snapshot's in distrobution... i find that just wrong, imho
This is just "a snapshot of the day" - this was a snapshot from a good time before we went gold, and after that we spent lots of time QAing it and fixing it.
When they released 6.0 and broke so many things.
Well, this RHCE is now quite frustrated. Looks like the Kickstart images I made are going to have to be modified to remove the gcc 2.96 packages and install 2.95.2.
Dreaming of a RedHat X.0 release without a HUGE b0rkeness in it.
-Rusty
The Master (Angelo Rossitto) in Mad Max Beyond Thunderdome, "Not shit, energy!"
"make mrproper" has been around for a long time. If you never bothered to read the readme's, it's your fault, not the fault of the distribution.
I've been working on a port to Itanium using Intel's simulator. The gcc included with it is picky. So picky that I think there is a bug (with regard to const strings and the ?: ternary operator). But I haven't been able to find a mailing list or anything to send my questions to. Who who who??
--
An abstained vote is a vote for Bush and Gore.
Non-meta-modded "Overrated" mods are killing Slashdot
(Hey Ryan! Here's your proof!)
When talking about what came first: the chicken or the egg, GCC is definitely the egg and GNU is the chicken. (See also the picture on gcc.gnu.org .)
:-) , etc.
Without GCC, there wouldn't be much Free Software around. Even non-GNUish Open Source projects (most namely BSD) use GCC. Even interpreted languages use GCC, as their interpreter is often compiled
GNU software with a >= 1.0 version number is usually well-thought-of and extremely reliable. To name a simple instance, I think that for the most UNIX utilities, the GNU versions just work better than e.g. Solaris or BSD versions. GNU tar's -z option rocks, as does the option parse system of e.g. ls , so that you can write ls foo -l as well. Bash is also an example of a solid piece of GNU software.
You'd think that these FSF "rock solid" GNU folks would be more careful about the "egg" of their project, GCC. But what do I hear here? Buggy "stable" releases, binary incompatibilities between minor releases which are only resolved by incompatible fixes for a new major release... It's kind of a mess.
I've also got the impression that with glibc the same issues arise, but I might be wrong.
How can we have closed source vendors run to open source systems when things are like this?
It's... It's...
"We can confirm that Debian does *not* ship the version with the trojan horse. Our version predates it." [CA-2002-28]
It has come to our attention that some GNU/Linux distributions are
currently shipping with ``GCC 2.96''.
What version of Debian did that?
I've been using Redhat since v4.2 - Generally I've had no real greif with what they've done, for the most part Redhat turns out a good product. Upon installation of RH7 however the decision that it was time to switch teams suddenly became alot easier to make - I'm now happily using Debian.
For starters, I had to wait literally hours to get disc two only to have it install ONE ROTTEN PACKAGE! Basically all that time was wasted so the RH installer could install sudo!
After that was finished I went to compiling kernel 2.2.17 only to find that it would compile at all! Frustrated I got my other linux box pulling down ISO images for a certain other distro.
In a nutshell, the fine folks at Redhat helped me make the decision to use Debian - something that I've always wanted to do but have never had the motivation to get around to. I'm never going back.
1. Mandrake 7.0 ships with a messed-up linker. Red Hat 7.0 ships with a compiler that's not even officially released. What's going on? Don't these companies know how important this stuff is (primarily when you've often got to 'make' your own binaries)? 2. I guess they could plead ignorance, but doesn't Red Hat have Cygnus in-house? Don't any of these people talk to each other? 3. Why do I have the sneaking suspicion that somewhere along the way this was a management decision? "Make sure to give it all the bells and whistles, guys! By the way, have we started work on the first service pack yet?"
--------
Bleah! Heh heh heh... BLEAH BLEAH!!! Ha ha ha ha...
I certainly hope so... with any luck, gcc 3.0 will go some way towards that goal.
When are we gonna see PetrOS? :P
Well folks, this clearly does make matters more difficult, both for the GCC Steering Committee, which now has to deal with the repurcussions of Red Hat's decision, and for people who use "2.96", which will not be binary-compatible with 2.95.2 or upcoming 3.0.
However, I don't think choosing which GCC version to use was this simple a matter for Red Hat. After all, they needed to maintain compatibility with the Linux kernel on the one hand, and have better I18N support on the other. The reason Red Hat included "2.96" was because they desperately wanted better I18N support... I'll bet it was probably because they are trying to compete on the international front, most particularly with GUESS WHO (hint: SuSE and TurboLinux). Heck, I'll admit I'd have a hard time deciding on this too, especially when it could mean $$$ for a company which has yet to make a profit. Then there was "KGCC", because after all, who wants a distro that has a non-working kernel?!?
I do think Red Hat has been a bit too eager to include bleeding-edge packages in its distros, but in some cases, including this one, it is NOT just done without careful consideration. I think they should be cut just a little slack on this one.
Try the gcc webpage - gcc.gnu.org
Bah! Icky CORBA.
Why not just define decent abstract base classes use them, and be done with it. But, I suppose that wouldn't work if you had to change the interface. *sigh* I hate CORBA. It's an even uglier mess than the C++ ABI, and it lets people believe they're making functions calls when they're really sending network messages.
Need a Python, C++, Unix, Linux develop
I just bought Red Hat 7 and installed it on a new drive after six years of building my Linux system by hand, thinking by now Red Hat must really be good and I don't have to mess with compiling and installing everything by hand any more. What the hell, RedHat!
So does this mean that the next major version of GCC will break everything with C++? Did the GCC have a warning or anything in it, saying it was a development version? Will the next Red Hat have, like, 5 versions of the libraries?
I happened to be looking at the Trumpet page this morning... FireSock looks like the ideal solution for NAT on Windows, and Trumpet also operates an ISP. I doubt they're going backrupt anytime soon - in fact, they look interesting enough that I took a gander at the Employment page and am kinda hoping they've got something going when I graduate in a couple of years...
"Really, this is a bit much! Distributions already don't usually run each other's packages"
:-( Not happy.
Horse pucky. I can install _a single set of binary packages_ heavy C++ I might add... say, Corel Office, compiled for RH on SuSE and it works
just fine. When I make a set of RPMs for distribution I usually only make 1 set, and they install just fine on RH, SuSE, Mandrake and Caldera (Yep, I test, in VmWare).
I mean come on! RH is _not_ the largest (by volume and sales) SuSE is (or is close, world wide) so you can't say that binary compatibility does not matter. Now we have to make 2 sets of binaries, one for the proper gcc (2.95.2 and libs) that runs anywhere, and one for RH's bastard gcc and libs
According to the GCC release timeline, there has not been any official releases since 2.95.2 on 24 October 1999. Major releases appear to be released once a year, so the next one should be due any time now. However, the lack of any minor releases in nearly a year - rather than every three to six months - gives the impression that development has stalled. While I'm sure GCC 3.0 will be as great as previous major releases, it's little comfort for those just want small, minor improvements to the current version.
If they want to stick discontinued, Pre-Alpha, Alpha, or Beta code in their final product, then by all means let them do it. The code IS freely available, right? It's freely available so people can use it, right? If those people happen to be the people at Red Hat, and they decide to put an unfinished product in their distribution, then it's their business... literally. If people don't like it, then they sure as Hell won't use it. Red Hat's commercial. They're free to make their mistakes all by themselves. Deal with it.
This is a manual virus. Copy it to your sig and help me spread!
Working with RedHat everyday I get to see all the wonderful things that they break....
A really good one is the damn -n switch for ping on 6.2. You wouldn't believe how many times I thought I had network or host issues when the host really just didn't reverse dns. That was and is a stupid thing to do.
They have also been really good about shipping packages taht are either way too bleeding edge.
It would be really nice if there were more people who understood management issues as well as technical issues, who could swim in both ponds. Put such a person in charge and you could be sure that important issues from both the management/business/marketing side of things and the technical side of things would each be properly dealt with.
As it is now you've either got a technical genius who knows nothing about how to run a business, or a manager who knows nothing about technical issues. People who are a little of both are rare. Bill Gates is the obvious exception to this rule. Sometimes it isn't that bad of a problem if the mangager is willing to listen to the people who understand technical issues. Someone who is smart and wise enough to understand what it is that they don't know and listen to those who do know those things is always an asset. But when you've got a manager who due to some psychological or emotional malfunction is unable or unwilling to listen to others, then you've got big problems.
A company which can't attract and keep good customers because their product's quality has declined or is no longer competitive will itself decline. In that situation even the best manager can do nothing more than delay the inevitable. When management isn't willing to listen to the people upon whom their profits truly depend, those managers are maiming and sometimes murdering the company they work for. Ion Storm, John Romero's new company and producer of the not so thrilling Dikatana, is the perfect example. From what I hear they had a psychotic in there running the show and of course causing such huge upsets that half the developers walked on the same day.
I think this is the reason why CIS degrees are popular. The idea being that a graduate of such a program would be skilled in management and aware enough of technical issues to be able to make decisions. The problem is that CIS majors don't learn much on the technical side of things. I work at a university in the college of business so I have some concept of what they are studying. Imagine a handful of elementary programming classes in C++ and Visual Basic in addition to some database stuff? The rest of the degree is all business related. A person like this may be more dangerous than a clueless manager because they might remember just enough from their classes to be truly dangerous, especially if they think those classes qualify them as an expert.
I don't know what exactly is going on at Redhat. You would think that simple testing would prove to even the most pointy-haired of managers that 2.96 simply didn't work right. Things like this don't happen by accident. Either there was woefully insufficient testing, or the results of the tests were ignored. Sometimes people with good track records mess up. If that is the case here then very little needs to be done other than make sure the person or persons responsible understand where they made a mistake. If however this is due to someone who is a screw up or causes problems, get rid of them.
Creating a company is not easy. Finding the best people you can find and constructing a work environment and system that maximizes the ability of each person to do their job can be tricky. But it can be done by people who know how. Such people cannot be deluded about their own self importance. They must understand that they are the grease that coats the gears to allow the real work to be done. The moment they forget this and begin to think that, due to their usually higher salary, that they are a gear is when the friction will begin to mount.
Lee Reynolds
Muslim community leaders warn of backlash from tomorrow morning's terrorist attack.
Shouldn't the version of gcc in the distro be the one they compiled the kernel with?
I watch the sea.
I saw it on TV.
No, Thursday's out. How about never - is never good for you?
... since I haven't seen a bad Slackware release yet.
You obviously never used the Slackware '96 release. Among other things, when I tried to install it:
- It kept trying to write the boot loader to the CD-ROM drive
- It tried to eject the hard drive at the end of the install
- It didn't create the "/dev/console" device
All in all, I wasn't overly impressed.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
I use it daily. And I've been stung by misoptimizations enough that I no longer even bother trying anything beyond -O1 on critical code. And this is on i386. RedHat releases on Alpha, which you admit "wasn't great." A lot of Alpha issues got solved post-2.95.2. I have no inside knowledge of RedHat, but this might have weighed fairly heavily in their decision.
I've used GCC since 1.X days, and it used to be that it was the equivalent or better of almost any vendor's compiler. That's no longer true. Where I work, GCC 2.95.2 has such a bad rep for miscompiling or crashing that nearly all production code is compiled with EGCS 1.1.2 -- or GCC 2.7.2.3. We might just be unlucky, or perhaps GCC 2.95.2 has more problems when dealing with legacy C++. But the latter would still be a major defect in GCC.
As to whether 2.95.2 is the "buggiest": I have experienced more grief from 2.95.2 than any earlier release. I have seen more people have problems with it than any earlier release. I've managed to avoided the 2.8 series, though, so I'll have to take back my claim of 2.95.2 being the "buggiest," since judging by its repulation 2.8 might well have been worse.
As for what Debian uses, 2.95.2 is also the production compiler for FreeBSD 4.x (which is most often where I use it, though I do some development on Linux and Solaris as well). And unlike Debian, the FreeBSD folks are not at all happy with it.
I agree that GCC testing has improved a lot; I've scanned the GCC developer's list from time to time, and I'm quite impressed at how much rigor has been added to the testing process, and how it has been made an integral part of development. This is probably why snapshots seem to be a lot more solid than they did early in the EGCS project.
This is why 2.95.2 was an enormous (negative) surprise to me. I'd talked up EGCS and the EGCS development process from EGCS 1.0 on, and converted a lot of folks to using EGCS. I had even greater hopes for it when it was made the official GCC. The testing regime seemed promising, a lot of good developers (including yourself) were slaving away at making GCC better and better, so I fully expected something "better than EGCS." Perhaps calling it "the buggiest" is a bit of an overstatement, but I feel disappointed and a bit betrayed.
TheDraw was an ANSI text art/animation program used on BBSes in the 1980s.
It was basicly used to make ANSI text animated art (using color and curser codes and extended ANSI graphic text)
Someone hacked it and released it under a new version number.
The authors of TheDraw had to offer an alternet release version..
Then there is the Cyrex 586 and 686...
The Cyrex 586 was an enhanced 486 not a Pentium clone..
Now RedHat releases an unfinished GCC and gives it a version number...
Three issues come to my mind on this...
1. If it's not an offical release it should not be included.. if you need it wait for the offical release before releasing your distro....
Offer an update pacage with a warning "sticker" if you must but DO NOT RELASE A FULL DISTRO WITH ALPHA, BETA or worse PROTOTYPE SOFTWARE...
If the people writing the software don't think it's ready there isn't any reason to overstep the judgement of thies people...
Unless they can not be trusted to start with and in that case you shouldn't trust the software they write at all.. stable, prototype or anywhere in between...
2. Version stampping someone elses software is a big NoNo.. At best it creates a problem with the version numbers.. at worst it could create confusion.. if the GCC people didn't know they might release an offical release with the same number... a person could still think this build was a stable release and treat it as such...
3. The idea of releasing a distro with support (The busness modle RedHat selected) includes provided added value by dubble checking STABLE open source software using the standard closed source checks.
By checking prototype software your basicly bypassing the open source quality checks and going entirely with the closed source quality checks that give us such quality software as Windows 95.
I'd like to explain here...
Before Microsoft released Windows 95 they went all over it to find every bug. They did wide beta testing handing out CDs for free as well as using paid beta-testers. It was a very involved process.
Mostly this was sparked by the early OS/2 Warp release.. Warp had bugs.. Microsoft basicly hyped that Win 95 was bug free and they needed to make Win 95 accually meet the hype becouse at that time they belived if they failed then IBM (The masters of FUD) would flash FUD Microsoft into oblivion.
All this effort did NOT result in a bugfree Win 95. Shortly after release someone fould that Win 95 left remote access ON by default with no password. Microsoft quickly fixed the mistake.
(IBM didn't FUD Microsoft over this and thus was the death of OS/2)
The point of this story BTW is not how much Windows sux (Microsoft fixed the bug quickly.. Thats how it works in open source.. find a bug fix it quickly.. and thats what happend here...) but for all the effort Microsoft put into making Win 95 perfict they couldn't make it bug free.
In short.. if the people who write the software think it's bug free.. check it be sure.. if they think it isn't bug free... then don't include it...
and DO NOT give a release version number to an unrelased pacage.. give the test or built number instead.
But don't think your people can stablise prototypes all alone. Microsoft dosn't even think they can do that.. they went for a wide beta instead.. and even THAT wasn't enough..
Part of why many can produce consistently reliable and bug free software is that the software they write is very simple. But Windows isn't.. nither is GCC.. pacages like thies need a great deal of checks to be sure everything works as it should.
RedHat should not bypass this process to get a quicker release date.
I don't actually exist.
But when different (GNU/)Linux distributions can't run each others' binaries, you have exactly the same situation the Linux company chiefs say they won't allow to happen: effective forking of Linux. Really, this is a bit much! Distributions already don't usually run each other's packages "out of the box," as it were. Not to mention that in an operating system which spans so many architectures, *partial* binary incompatibility is really not so great a concern!
Although I understand you have a personal interest in this software, please keep in mind that it is GPLed. It is extremely disingenuous for you first to release it the public for general use, then to turn around and so harshly criticise someone for the crime of taking you up on your offer!
Redhat has a bad habit to put things in the ditro that is too Bleeding Edge. They always have to fix it up in the point releases. In thier rush to look like they are in the front of the game they shoot themselves in the foot.
suggest that builds are actual successors to earlier releases. The
Mozilla milestone approach, and the linux-kernel `test' and `pre'
releases can help to avoid this.
Still, it is exceptionally incompetent of Redhat to release a
distribution based on code generated using an unfinshed compiler whose
binaries are incompatible with existing official releases.
Hello, I am a relative newbie to linux, and I have not been having a good time with redhat 7.0 at all. I have not been able to get any kernels to complie with it, even when I changed the hostcc variable in the Makefile to kgcc. I have used redhat 6.x many times before to build a kernel with no problem, so I do not believe I have done anything worng. My question is how can we get back to version 2.95.2? I have tried to uninstall the 2.96 rpm files, but every time I uninstall one, I find that it tells me there are more 2.96 rpms left. If someone could please tell me how to iuninstall the crappy redhat 2.96 gcc compiler, and get back to the standard one, I would really appreciate it. If anyone could even give me a suggestion for compiling my kernel, it would be great. I am new, so if I have missed something, then i'm sorry, but I oculd really use some help here. I don't want to go back to redaht 6.2 because I have a geforce2 and soundblaster live (both of which redhat 7 detects and installs drivers for), and I liek the new sawfish manager for gnome (and don't want to have to install 20-30 binaries on top of redhat 6.2 to make it close to redhat 7. If someone can help, my e-mail is mahtgod79@hotmail.com. No spam please. Thanks
Man, C++ still aint workin super well, 2.95.2 was still choking on some of our > code, that gcc 2.7 did fine with. And its been months since they made an official release. I, for one, applaud RedHat's engineers for doing an end run around gcc's overly conservative release schedule. Otherwise I'd have to be the one applying all those patches to the cvs snapshot. Now I have a concrete version to test against, that other developers can reproduce in their environments. Thank you Red Hat!
You didn't get your ia64 gcc version from the GCC steering committee, as there is no official ia64 release yet. So whatever you have is an early snapshot. Any ia64 gcc you can find will be a highly experimental, buggy piece of software. You might be able to get some help from the folks on the Linux IA-64 project.
Shouldn't this have came up in testing. After all isn't that why betas exist.
Okay, so one is not supposed to use the development snapshots. Fair enough - but is there any word on when GCC 3.0 will be out, then? The current C++ support is somewhat lacking and I hope to see it improved in the next release.
(Yeah, yeah - I should go and do it myself instead of bitchin' about it. Sorry, I am busy doing the stuff I was told to do last time I bitched :-).
--
what percentage of software included in Redhat actually is an "official release version?" I can understand not wanting people to think your software is crap because someone else is distributing a bad version of it, but what a great opportunity to get eyeballs to shallow your bugs!
All kings is mostly rapscallions. -Mark Twain, The Adventures of Huckleberry Finn
It's not really fair to leave out Richard Henderson's explaination on linux-kernel...
Basically he says 2.95 isn't that great on non-x86 platforms and their version is much better, and that 2.95 already has incompatibilities between egcs 1.1 and the future gcc 3.0 so it doesn't make a big difference.
Personally i don't care much (i don't have a box running any distro anymore except Slack7.1 boxes that are being moved to LFS) but does 2.96 have trouble compiling software?
I can understand a major release as 3.0...but RH doing this doesn't help anyone, nor the community.
-
and they've tried very hard to get the rest of the industry to believe that Red Hat === Linux. I can't necessarily fault them for that; they have a fiduciary responsibility to their shareholders, and such microsoft-like tactics are the best way to build the RedHat brand.
Hey: at least they didn't take the stock-ticker symbol LNUX.
Before tending to their splinters, may I respectfully suggest you look to your own eye?
From the gcc working group's message:
WTF??? After all this time, they still haven't got C++ name mangling figured out? What the hell have these guys been doing all this time, playing solitaire?
I know maintaining a compiler is hard. But C++ name mangling is so fundamental to the function of the language that there's absolutely no excuse for this. Designing an extensible and robust name mangling scheme should have been the very first thing that was done prior to writing a single line of code for the C++ compiler. That they're changing the name mangling now makes them look like fools (of course, they could argue that they're fixing something that was broken from the very beginning, but that begs the question of why they haven't gotten to it until now)...
--
Use 'slashdot stuff' in the subject line in any email you send me if you want to get past the spam filter.
The fact that this statement is possible worries me. First of all, it would be really nice for me as a developer to be told that library "A" is standard for all Linux distros, and they can feel free to (dynamically) link against it, with reasonable assurance that all "Linux" platforms will have library "A" and therefore run. Plus, with certain applications (read: Mozilla/XFree86), I'd rather install pre-built binaries simply because attempting to compile everything is usually much more time consuming to do than using pre-built binaries, and is also more likely to run into problems.
It would be nice to think that any binary compiled on any Linux system for a given platform would run on any other Linux system on the same platform with a compatible set of libraries (ie, an app linked against glibc 2.1 had better work on my system with RedHat 7.0's glibc 2.whatever). After having Nautilus bomb on me because I didn't have the appropriate compression library v0.9. This really annoyed me since I had a v1.x (forget the x) version installed. It's a newer version! I'd like it to work!
Actually, people breaking compatibility from a beta to a release is OK. But if glibc2.2 breaks glibc2.1 appps, that'd just be bad. Those who use Windows are familiar with "DLL Hell." Sounds like Linux developers are starting to create "Library Hell." This would be a very, very bad thing.
You are in a maze of twisty little relative jumps, all alike.
But doesn't Red Hat own Cygnus, ie, the single largest part of GCC development? Couldn't they just ask them?
I heard a while back the reason MS has problems was (partially) because they had no intercommunication between, say, the browser, the kernel, and the office suite teams. I always thought that free software development was better, you could just ask the next guy "Hey, does your Foo work with my Bar?" But if Red Hat can't manage to phone their other building and say "Hey, is your GCC ready for any kind of release with RH7?" it's kind of disconcerting.
Oh well. Time for me to start evangelizing Debian to all my friends again.
Windows 2000: Designed for the Internet. The Internet: Designed for UNIX.
Redhat can do whatever they want. After all, they invented open source.
The idea comes from one of the gcc developers. See the posting on LWN.net.
...considering four out of the fourteen members of the steering committee are from Red Hat.
Here's how I see the problem...
It's a problem of the mapping between function name, and location in the virtual table. If you set it up so that mapping happens at runtime (but just once), then adding new methods isn't a problem. Only removing methods, or changing the semantics of an existing method is a problem.
If you don't stick with abstract base classes, then you add class size to the mix. Many parts of a C++ program invisibly depend on the size of a class. In particular, array declarations or pass by value arguments and return values. Also, if you call inline functions, you end up with code that depends on the actual layout, type and name of member variables. This is a real pain to deal with.
You could have some kind of hash that was kept of what the two linked components expected the insides of the class to look like, and if the hashes differ, refuse to link and tell the programmer that a recompile of one of the two components was required instead.
Need a Python, C++, Unix, Linux develop
I don't agree with RedHat's decision to ship what was essentially a snapshot, in RedHat's defense I have to say that they were faced with a dilemma. They could either:
They chose the last option, knowing that there was no possibility of having 3.0 compatibility aside from option #2, and that they'd at least get a stable and largely standards-compliant C++ compiler.
After RedHat chose a snapshot, they continued to follow subsequent snapshots but because of the necessities of release engineering created patches against the original snapshot, which has lead to the accusation (largely unwarranted) that they have forked GCC.
Personally, I think they should have stuck with 2.95.2, warts and all, but it was a judgement call for them, and the path they took is not without some justification.
(BTW, the FreeBSD folks are so disgusted with 2.95.2 that they're considering making a similar move.)
Yep, answers, a dime apiece, guaranteed to be worth less than what you paid for 'em... :)
Warning: I am a C++ programmer. A pretty good one on the whole, I think. C++ is my favorite language to use and develop in, but I'm not a C++ zealot; I also use (and enjoy) Java, C, LISP and Pascal. (Yes, I like Pascal. Get over it.)
I do not understand why c++ is shunned by so many c programmers.
Usually because they're not very good programmers. That's the answer, point blank and simple. No language--emphasis, no language--is a universal win; every language has tradeoffs and balances. People who harp about how faulty C++ is have probably never opened their eyes enough to take a look at how faulty their favorite systems are.
There used to be a guy where I work who ragged on me day and night about how stupid I was to like C++, or how "bloated" C++ was, or... etc. All he wanted to do was rag on C++ and harp on C. One day I got to take a look at his C code: and let me tell you, the guy couldn't code his way out of a paper bag, even if I gave him a hand grenade.
You see the exact same thing happen with C++ zealots who scream that Java is stupid. They rant, they rave, they scale the walls... and they do this, I've usually found, because they're bad programmers. This is not limited to C and C++ holy wars: in almost any holy war, you'll find the people who are speaking the loudest are the people who know the least.
If you want to know why C++ is shunned by so many C programmers, there's really only one way for you to find out. It's a two-step process.
1. Become a C++ hacker.
2. Become a C hacker.
Once you do that, you'll see that a lot of the holy wars between C and C++ are completely bogus. Computer languages are just tools; a hacker learns how to use lots of different tools, and then uses the right tool for the job. That's all.