Hi Jes,
my gripe was not concerning the glibc 2.2. There I was happy that it
finally triggered and spotted the problem in the code (btw not in my code
but it could have been in my code, nobody is perfect). It was not a
complaint only a remark for people moving to RH7.0. [Anyway the fpos_t
error was somewhere in a piece of code of 600000 lines, and I don't accept
arrogant bullshit statements from anybody about coding *by accident* and
not *by design*, even with a smiley].
Concerning the compiler. I've already been sent this justification by a
RedHat employee in reply to one of my bug reports. Btw the bugs I mentioned
are still all there in gcc 2.97. The C++ API might be complete, but if I've
to change perfectly legal code to use it, it does not help so much that the
API is complete. Or that the numerical results the program produces are bogus.
Applications providers are not screwed by the pre-glibc 2.2, at least I've
not seen any problems there (the problem I mentioned was our own broken code,
which is now a bit more future proof). More serious is the compiler and I
don't buy the justification to ship a development compiler far from being
gcc 3 on an official release. Rawhide is for wild developments, a wide
audience release like RH7.0 is not. People should not be considered stupid
for installing 7.0.
Maybe, instead of having provided a version of my program working on 7.0
I should have answered to the guy who asked me for it: hey, if you install
Red Hat 7 at this point and expect everything to work out of the box then
it's really your own problem. Contact me again when RH 7.2 has been released.
With a growing community comes a growing responsability. That's the
burden of success.
Ciao, Fons.
PS: I was really disappointed that the default kernel was not
2.4.0pre*-test*. :-)
Jes Sorensen wrote:
>
> >>>>> "Fons" == Fons Rademakers <Fons.Rademakers@cern.ch> writes:
>
> Fons> Indeed the 2.96 compiler is very buggy and if it does not segv
> Fons> itself, it produces numerical incorrect code with any optimization
> Fons> higher than -O. Porting ROOT resulted in compiler segv's in three
> Fons> files (and three bug reports to gcc-bugs). Two of the segv's
> Fons> happened with -O2 and disappeared with -O and one happened with -O
> Fons> but I could work around it with some change in the code. So in the
> Fons> end I could compile everything with -O. Compiling with -O2 (except
> Fons> for the two files that failed and that were done with -O) resulted
> Fons> in an executable that produced so many errors in double precision
> Fons> code that I did not even try to look in detail at the problems.
> Fons> Note that by default on Linux with egcs 1.1.x and gcc 2.95.2 we
> Fons> compile with -O2 and obtain correct results.
>
> Hi Fons
>
> Allow to point your attention to the attached article posted to
> linux-kernel about the choice of compiler in Red Hat 7.0. For those who
> don't know Richard, let me just say that he is one of the core gcc
> developers who has contributed incredible amounts of work to both gcc
> and Linux.
>
> In your gripe about gcc in Red Hat 7 compares it with gcc-2.95.2 which
> is known to be broken and quite a few gcc developers directly tell you
> to stay away from it. This of course doesn't stop the usual bunch of
> I-know-better-than-the-guy-who-wrote-the-code people from screaming
> about how they have compiled the Linux kernel with it for ages and it
> never failed for them. Or should we say, they never noticed the problems
> in their specific configuration or because they don't run the kernel
> long enough to notice. Never mind that gcc-2.95.2 has been abandonned
> for a long time by now and is incompatible with gcc-2.96+.
>
> As Richard points out, gcc-2.96 at least has the property that the C++
> API is complete, though the ABI is not, so once you have ported your
> code to the new compiler it is very likely to work with the final
> 3.0. Going for 2.95 would just give you yet another interem step to go
> through.
>
> With regard to the bugs you found in the compiler I asume you posted
> those to bugzilla.redhat.com as well as gcc-bugs. If you expect Red Hat
> to catch the bugs and fix them you need to tell them directly about it,
> plus it is of course their problem to fix their mess, not the regular
> gcc developers.
>
> Fons> Another issue is that RH7.0 comes with a pre-release of glibc
> Fons> 2.2. This new version is not compatible with the previous glibc
> Fons> 2.1 and in some cases requires some porting effort. Assuming that
> Fons> the data structures used by pre-glibc 2.2 stay the same in glibc
> Fons> 2.2 this is not such a big issue as the bad compiler. One of the
> Fons> incompatibilities I ran into was that the type fpos_t used by
> Fons> fgetpos(), fsetpos() is now a struct and not anymore an long, so
> Fons> code like: fpos_t oldpos, pos; ... if (oldpos == pos) ... fails
> Fons> to compile.
>
> As Dan Pop already pointed out to you your code is broken so this
> complaint is void. glibc-2.2 in Red Hat 7.0 is a 2.1.94 beta snapshot
> which is very very close to what we expect to see shipped in the final
> glibc-2.2. I do not anticipate ABI changes though it of course cannot be
> ruled out if someone discovers a major bug tomorrow that requires a real
> change. In that case it is Red Hat's job to solve the problem in their
> distribution though.
>
> I have been working closely with the core glibc developers over the last
> 6 months and glibc-2.2 is in a very good state right now.
>
> Fons> Application providers are really screwed by RedHat. Of course
> Fons> people will install RH7.0 and of course they expect their apps to
> Fons> be available. And the app providers have to clean up the mess!
>
> Fons, have you been reading too much slashdot recently? Why are
> application providers screwed? glibc-2.2 *is* the new standard libc in
> Linux and it is what you can expect the LSB (eg. Linux Standards Base)
> to standardize on, all vendors will switch to it at some point or stay
> non standard. If you install Red Hat 7 at this point and expect
> everything to work out of the box then it's really your own problem.
>
> Fons> Everybody who wants RH7.0 for the new GUI features and other apps,
> Fons> should at least install 2.95.2 if they also want to run scientific
> Fons> codes.
>
> *NOBODY* should install gcc-2.95.2 if they want any code to run at
> all. Mixing 2.95.2 and 2.96 is brain damage and is going to cause you
> problems, what you should do is to help iron out the problems/bugs in
> 2.96 and move on from there. Your gcc-2.95.2 compiled application will
> definately not work with the libstdc++ libraries in the system which are
> compiled with 2.96.
>
> Installing gcc-2.95.2 now is like deliverately blowing off your leg with
> a machine gun.
>
> So I am not particular fond of Red Hat shipping all these items in Red
> Hat 7.0 already, IMHO the should have waited until glibc-2.2 at least
> was released as a release candiate, in particular as glibc-2.2 is very
> close to shipping in the final version. However the choice of compiler
> was correct and the same goes for them shipping a CVS snapshot of
> XFree4.
>
> Jes
--
Org: CERN, European Laboratory for Particle Physics.
Mail: 1211 Geneve 23, Switzerland
E-Mail: Fons.Rademakers@cern.ch Phone: +41 22 7679248
WWW: http://root.cern.ch/~rdm/ Fax: +41 22 7677910
This archive was generated by hypermail 2b29 : Tue Jan 02 2001 - 11:50:34 MET