[svlug] Mandrake 8 beta thoughts

Rick Moen rick at linuxmafia.com
Wed Mar 7 15:10:02 PST 2001

begin  Drew Bertola quotation:

> Can you be exact to what is broken in "2.96?"

Once again:

C++ object-file compatibilty (with code from both earlier compilers 
and the eventual 3.0 release).  Also, choking on some valid C++
constructs.  There are, additionally, sporadic but ongoing reports of
clean _C_ code erroring out on "2.96" but not 2.95.2, 2.91.66, etc.


Not to mention that version-numbering, which they should not have done.
(There is no v. 2.96, and now there never will be.)  Other distributions
have been equally guilty of such things in the past, such as Debian's
so-called glibc 2.07.  But that doesn't excuse it.  Maybe 2.95-rh1,
following the example of version foo-ac kernels?  3.0-pre1-rh?


A good statement of the (compelling) reasons _for_ "2.96":

I'm sympathetic to the need to drive forward and properly test gcc 
(and glibc 2.2, and kernel 2.4.x).  Aside from the version-numbering,
I _think_ I'm on Red Hat's side, here, maybe:  They're showing necessary
leadership.  But people should be warned of potholes (and of the option
of using "kgcc" on stock RH7 -- and of making it the default compiler).

There's also the problem for publishers and users of proprietary code:
There are now two x86-Linux target binary platforms (where C++ is
concerned).  Should publishers target both?  Or one, and, if so, which?
Or eschew C++ shared libraries (perhaps the best choice, overall)?

(In fairness, the C++ binary interface has never been very stable.
Ironically, in the long term, RH's move will help stabilise it.)

Cheers,                              "Open your present...."
Rick Moen                            "No, you open your present...."
rick at linuxmafia.com                  Kaczinski Christmas.
               --  Unabomber Haiku Contest, CyberLaw mailing list

More information about the svlug mailing list