GCC 3.2 Released

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!"

Comments

Re:Breaking interoperability... again???

[edhall]

They also promised that the ABI was finished in 3.0. In fact, that was one of the reasons given for taking so long in getting 3.0 out the door. Not a good track-record, IMHO.

Still, it will be good to get closer to standards-compliance. C++ has been standardized for four years, now, and fully compliant compilers are just now starting to appear. GCC has actually been fairly good compared to some (cough, Microsoft, cough) in adhering to the standard.

-Ed

Just compiled a kernel with it.

[Neon Spiral Injector]

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.

Precompiled headers

[FooBarWidget]

Does anybody know when GCC wil finally support precompiled headers?

What does this mean for OS X?

[frankie]

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...

Switching Compilers

[Catskul]

From what Im reading in the comments, there can be problems when upgrading compilers across ABI versions. Can someone either summerize the possible difficulties, or point to a place on the web where I can read about them. What I mean is: If I switch from gcc 2.9x to gcc 3.2, what will I not be able to do, and what problems can I expect

Stable C++ ABI???

[Anonymous Coward]

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!

Re: kde speedups ?

[Antity]

Where does the gcc 3.2 release stand in terms of fixing the linking speeds of C++ programs?

Isn't this rather part of ld(1) (binutils)?

C++ stability

[Compuser]

If C++ ABI is now declared stable does this
automatically imply that GCC is now fully C++
standards compatible? If not then what is
left to change?

Re:(Sorta-kinda OT) - GCC3 and GCC 2.95.3 coexist?

[FooBarWidget]

Use a different prefix! I have 4 different GCC versions on my system (2.96 and 3.0 both provided by RedHat, and 3.1 and 3.2).
I configure GCC 3.2 like this: ../gcc-3.2/configure --prefix=/usr/local/gcc32 [misc unimportant options here]

This way, *all* files will be installed in subdirectories inside /usr/local/gcc32. The binaries go to /usr/local/gcc32/bin, the libraries to /usr/local/gcc32/lib, etc. Removing GCC is as easy as rm -Rf /usr/local/gcc32

To make sure GCC will work:
- make a symlink /usr/bin/gcc32 to /usr/local/gcc32/bin/gcc
- add /usr/local/gcc32/lib to /etc/ld.so.conf and run ldconfig

I just installed GCC 3.2 an hour ago, but I installed GCC 3.1 using the same method (except that the prefix is /usr/local/gcc31) and everything work just fine; no problems whatsoever. I successfully compiled an entire GNOME 2 system using GCC 3.1.

Athlon performance?

[evilpaul13]

Have all the problems that arose in 3.0 regarding performance on AMD Athlon processors been resolved? memcpy() among other things were quite slow when compared to similar processors with GCC 3, and with GCC 2.95.

A mess for those running old/current distros...

[kcbrown]

Suppose I have a system that uses an older compiler and I want to put gcc 3.2 on it. No problem as far as naming the compiler and such goes, that's the easy part.

But now I have to recompile every single C++ library on the system in order to make the new compiler truly useful.

Yet, at the same time, I want to be able to run my old C++ binaries and also want to be able to drop back to my older compiler if necessary.

The best way to accomplish this, I suppose, is to put the new libraries in their own directory and modify gcc 3.2's spec file to include a -L directive to the linker to reference those libraries at link time and a -rpath directive at link time so that the resulting binary references that directory at runtime.

The other options I thought of involve either renaming the libraries (thus requiring manual intervention when compiling any package that would refer to the libraries by their "old" names) or changing their major version number (surely a serious abuse of the purpose of the major number! And it would cause problems when linking using the old compiler anyway). Neither of those are very palatable.

Anyone have better ideas on how to do this?