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.
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.
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.
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.
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...
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.
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)
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!
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.
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!
"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..."
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?)
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.
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.
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
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.
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.
Do Red Hat users every actually compile anything anyway?
(boy is this going to ruin my karma)
:wq
Oh, that's just silly. And, if you want to make it an example of "capitalism in action," include the part about their customers getting pissed, and refusing to upgrade and/or switching to other distros or even other OSes. It's pretty silly to take one specific bad thing and attribute it to a system-wide socioeconomic fault.
________________________________________
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
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 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]
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
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.
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!
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.
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.
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.
...considering four out of the fourteen members of the steering committee are from Red Hat.
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.)