Slashdot Mirror

← Back to Stories (view on slashdot.org)

GCC 3.2 Released

Posted by michael on from the fount-of-all-goodness-and-light dept.

bkor forwards the GCC 3.2 release announcement, without attributing it as such: "The GCC 3.2 release is now available, or making its way to, the GNU FTP sites. The purpose of this release is to provide a stable platform for OS distributors to use building their next OS releases. A primary objective was to stabilize the C++ ABI; we believe that the interface to the compiler and the C++ standard library are now stable. There are almost no other bug-fixes or improvements in this compiler, relative to GCC 3.1.1. Be aware that C++ code compiled by GCC 3.2 will not interoperate with code compiled by GCC 3.1.1. More detail about the release is available. Many people contributed to this release -- too many to name here!"

4 of 311 comments (clear)

  1. Just compiled a kernel with it. by Neon+Spiral+Injector · · Score: 4, Interesting

    Looks like it produces smaller code than 3.1:

    803130 Aug 15 13:18 vmlinuz
    804713 Aug 6 09:08 vmlinuz.old

    At least by a tiny bit. Those are both Linux 2.4.19 kernels with the same .config files.

  2. Precompiled headers by FooBarWidget · · Score: 4, Interesting

    Does anybody know when GCC wil finally support precompiled headers?

  3. What does this mean for OS X? by frankie · · Score: 4, Interesting

    This is really bad timing for Apple folks.

    AFAIK, the entirety of Jaguar is compiled with GCC 3.1. Replacing all the libraries with v3.2 is gonna be some mighty huge software updates...

  4. Stable C++ ABI??? by Anonymous Coward · · Score: 5, Interesting

    Finally a stable C++ ABI ???

    1. This means that C++ _including objects+classes+ will, with a bit of grunt work, be able to be integrated with real-oo scripting languages just as easily as C - it's the constantly changing C++ ABI that has prevented, until now, "easy" bridging of, say, C++'s object model to Common Lisp's CLOS, without having to recompile everything in sight at the drop of a hat - it will now be possible to produce a C++-to-lisp analogue of, say, CMUCL's excellent "alien:" lisp package (nothing to do with the deb2rpm tool), or SWIG-but-for-proper+C++ for python and perl.

    2. It will mean that third-party binary distribution of C++ code is a lot more viable. Remember the way Netscape, Realplayer and flash used to break with every new RedHat release? - well, that was primarily becuase of libstdc++ not linking properly due to changing ABI.

    3. This should also mean that the prelink "hack" and it's ld.so-integrated successor can stabilise and become part of standard linux distros - no mare agonisingly slow KDE startup times!